Status Core Dev Call #32 - June 15, 2020

Henrystats

on Jun 18, 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.

#

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`)

#

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

#

Added “Mitigation process” and “Privacy Policy”

#

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

#

[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

#

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

#

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