Status Core Dev Call #32 - June 15, 2020

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

• Meeting Date/Time: Monday 2020-06-15 at 12:00 UTC
• Meeting Duration: 2 Hours
• Video streams:

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

Agenda

1. Agenda setting (~5)
2. Announcements (~5)
   a. John Lea starting as Senior Product Design Architect
   b. Privacy Policy
   c. …
3. Review previous actions (~5)
4. Specs review > open PR’s for Discussion (~20`)
   a. Mentions
   b. Notifications (Android) - Draft
5. Expected changes/proposals (~10`)
   a. Notifications (iOS)
6. Stimbus (what, why, how) (10’)
7. Mitigation process (10’)
8. AOB (~5`)

Minutes

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

1. Agenda setting

• Added “Mitigation process” and “Privacy Policy”

2. Announcements

• Welcome to John
• Call with legal counsil for privacy policy. Not legaleze, but human readible; helping navigate GDPR > Discuss post from Ceri to follow

3. Review

[X] Jakub: Define process around pinning new stickers

• Issue: https://github.com/status-im/infra-ipfs/issues/7
• Ricardo: Related pinning IPFS or inclusion of new packs on smart contract?
• Ricardo: Discussed with Jakub, seems in progress
• Jakub: Something working. Bug in IPFS cluster library. Solution in day or 2 to make stable

[X] Barry: Add issue + PR for indexing proposal

• https://github.com/status-im/specs/issues/133
• Barry: Issue added for indexing, no PR. Unless it needs PR to update specs
• Barry: No firm opinion on what implementation should be
• Barry: Priority? Could be lo this/next quarter
• Barry: comes up with dapps; seems related to what Samuel is addressing
• Samuel: There is, interaction on Discuss post. Using The Graph API. Able to index in decentralized manner tx data
• Samuel: Lacking detail, on hiatus. Infura willing to work on feature (pending transactions)
• Samuel: User acquisition, this is a scaling issue. Dialed down pushing. No objection, but on back burner
• Oskar: In Discuss thread, questions on current Infura use. 1.3Mlj requests, rated at 5Mlj. What happens with 10x more users
• Andre: Considerations. Infura is not rate limiting (as informed by CEO), if we cross 5 MLJ unless rediculous no issues expected. Already overpaying. Confident we can work with them so that we would not be cut off, but can negootiate requests
• Samuel: figure 1.3 mlj. Average of usage over lest days. Question if bulk can come from own e2e testing. Implement dedicated tokens for testing. User consumption vs dev consumption
• Samuel: Focus on acquisition, will give a better idea on impact of 10x new users
• Andre: We’ll have a think. Would need to pay regardless for a new project (needs history). Set up different networks
• Samuel: Based on understanding and use of Infura. As many project end points as we want, can get statistics per project. Not even 5 min to create end-point.
• Andre: Let’s do it
• Samuel: to own e2e usage tracking after Andre provides access

[X] Hester: Follow up with Roman on issues Keycard PR

• Hester: Merged in the meantime.
• Rajeev: Some peer reviews on wording. There can be further enhancements done to the spec. Protocol interactions of Status app and react native. Can be other Keycard specs. Will work on some for articles in the coming weeks
  [ ] Eric: Merge Notifications PR as DRAFT
• Yenda: Asked for review from Andre and Dean. Notifications ready to merge, waiting for last comment.
• Andre: will look
  [ ] Andrea: Create issue on rate limiting and other variables to prevent network spamming
• https://github.com/status-im/status-react/issues/10775
• https://github.com/status-im/status-go/pull/1989
• Andrea: Discussions about rate limiting, push out specs, code merged. Matter of deploy and check that it works fine
• Andrea: Before number of messages in Waku. 5 messages per second. That’s fine, but what happens in chat. Many small messagees would be blocked, doesn’t help with bandwidth. 5 messages would not be rate limited
• Andrea: Rate limited by data introduced. Given node not more than 1mb per second.
• Andrea: Anyone can post. Limit by peer ID and IP address
• Hester: reflect in privacy policy; to do
  [ ] Hester: Follow up with Corey on contingency plan in case of App store ban
• Hester: Open todo To reach out to Tobias while Corey is out
• Oskar: Reason to not Post on Discuss, get input from other projects
• Hester: No reason. Time, will post something this week
  [X] Samuel: Ping Oskar for resources on incentive mechanism for data sharing

4. Specs review

a. Mentions

• Samuel: Linting issue
• Ricardo: how does client check message
• Andre: Sounds like text contains users public key
• Yenda: Normal message, string that starts with @ and pk of user
• Andre: UI turns that into name?
• Yenda: Yes
• Yenda: Linter doesn’t like lowercase;
• Samuel: add exception to word list
• Ricardo: Does implementation cost more battery? Read each messagee in public chat
• Yenda: Already the case because of markdown parsing. Already done
• Cammellos: Cost involved. Status-go will parse @name. Efficient, stop if not a mention. At runtime, extract pk, ENS name can changee. Not a lot of data. Not terribly inefficient, as it works fine, but questions around subscription list
• Ricardo: message always contain public key or may it contain ENS name
• Cammellos: never ENS, only public key
• Ricardo: Perfect
• Oskar: Any concerns when it comes to bridging. Unintended consequences. What happens if I mention when bridged?
• Cammellos: Would need to type public key. If you add ENS from bridge nothing will happen. Will only parse in Status
• Tobias: Reverse lookup, is it cacheed. When someone spams mentions do we perform lookup again?
• Cammellos: Lookup Batched. Limit at 30sec. You can theoretically send a lot of mentions
• Tobias: trollmind, mentions everyone in public channel. Can do this over again if there’s not caching
• Cammellos: Lookup is cached. Not looking up through mentions. No reverse lookup for ENS.
• Yenda: basically, only cost if you send package of mentions is check contact list names you’ve resolved if there’s pk there, mention, else show random name
• Tobias: No ENS name in contacts, don’t lookup
• Ricardo: if lookup can happen once, ENS is not included
• Yenda: autocompletion almost done, you already know ENS name. All names you already know, plus random name of people loaded in current chat
• Yenda: Only person forcing to do remote calls is you, but not initiated, only using names that are already known
• Tobias: If I can trigger someone else to perform a lookup; cost to have another node pay
• Cammellos: You can, not from mentions.
• Yenda: Sending names, many messages with different name and address
• Cammellos: Yes
• Barry: How long is user name cached for? Per session, longer period of time. Usernames can be changed. Swapped, associated with different address
• Cammellos: Don’t re-resolve ENS; not implemented. We should
• Tobias:
• Cammellos: Name can be changed at any point. Check weekly
• Ricardo: Subscribe to event regarding this ENS in resolver in ENS root. Get events from blockchain to update on demand
• Oskar: Move on, off topic
• Ricardo: Relates to mentions, autocomplete, you expect it to update
• Hester: Tobias, Barry to create issue
• Tobias: can create issue for name resolution

5. Expected changes/proposals

a. Notifications (iOS)

• Andrey: Started worrk with Andrea. Status-react sending push notification. Decided on iOS notification asap. Decided on faster way. Use Waku nodes, sending notification vvia Apple notification service. Send with notification sender needs to send message through Waku
• Andrey: Apple notification service without Firebase or other third party
• Andrey: Go library to trigger push notifications in apple service. Independent part implemented. Can send pn from go to iOS application
• Andrea working on Waku node implementation
• Cammellos: No time to put everything in writing. Can give description
• Cammellos: Main issue is centralization… Need apple certificate. Comes from Waku and not supposed to be shared. Seems what firebase does. You trust firebase with certificate. Needs service run by Status with certificate. Unless we share certificates, bad idea. Service needs to be 100% available as alternative. Depends how we want to decentralize around this. Run own service and connect? Slave notification services can reduce requirement to <100%. Only need public key from B. Don’t need to know device B is running. Great in terms of meta data protection, not the best in terms of bandwidth. And regardless of whether the other user is using iOS or Android. Can detail more how this will work between Desktop.
• More interactive; request, authorize, send notification if other user is using iOS. Less bandwidth, but device profiling
• Andre: Use this for Android as well
• Cammellos: Works
• Andre: Could be an option, but for future discussion. Ping on issue to keep everyone up to date or share on Discuss
• Oskar: Concern central certificate server and other nodes?
• Cammellos: 1) tell apple to send notification to user, needs to be centralized (only Status should have that power) 2) Tell server to send notification to user (REVIEW RECORDING)
• Oskar: Hypothetically: 2 iOS apps, 2 legal entities. Different version, apple account, own service. Would other nodes be able to add?
• Cammellos: Separation of concern. You would be able to
• Oskar: Useful to anticipate different platforms and constraints
• Cammellos: Discuss post, pros and cost that needs to be discussed
• Ricardo: iOS notification server and PFS, how does that relate and which public key does the server know. Fixed or changing
• Cammellos: To be decided
• Tobias: Ephimeral session key for specific iterations of forward secret protocol. Unique public that it needs to be derived from
• Cammellos: PFS not needed for this; only shows you have a new message
• Oskar: Not sure about state of Android apps. Notifications increase engagement. Seems reasonable
• Oskar: Can check retention rate
• Hester: Follow up offline with Jakub and Oskar
• Oskar: Create cohorts by looking at Peer ID
• Jakub: Doable, but not easy
• Ricardo: Question about battery use. Now battery use the same?
• Andre: Has been tested, around percentage points. Can look at data and share notes

6. Stimbus

Hester: Set up separate call + stream

7. Mitigation process

Tobias: If more than 10 people available can stick around now
Andre: Include result on that call on Discuss

AOB

None disccussed