Status Core Dev Call #30 - May 18, 2020

Henrystats

on May 18, 2020

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

Meeting Date/Time: Monday 2020-18-05 at 12:00 UTC
Meeting Duration: 1 Hour
Video stream:

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

#

1
Agenda Setting
2
Announcements

Stay tuned Stimbus
Next call Core Mobile and Core Desktop
There are new make file targets

3. Review previous actions

4. Specs review > open PR’s for Discussion

5. Expected changes/proposals

Notifications on iOS

6. AOB

#

https://notes.status.im/core-dev-call_30?view

Process around adding new stickers? Any other actions items?
No comments

#

Bunch of Open PR’s
Walk through what’s left to get these merged

Add spec for IPFS gateway for Sticker Pack
https://github.com/status-im/specs/pull/110
PR is ready. Waiting for one more approve
Someone of the Core team to do a sanity check in order to merge
Please review if you’re familiar with the domain
For Desktop team, ping if you need permission
Barry if indexing on IPFS outside of scope of PR
Resolving can take a little bit of time
Jakub: Pinning or something else
Barry: indexing for quickly resolving. E.g. using TheGraph. Quick lookup instead of traversing and loading. Indexing could speed that up
Oskar: Does that exist in the app? Or is it a proposed enhancement
If doesn’t existing add a separate PR

Keycard

https://github.com/status-im/specs/pull/109/files
Check when Roman is back

Dapp browser API

https://github.com/status-im/specs/pull/108
Seems to have had reviews already
One todo remaining from Oskar, Seems complete
Barry: there’s been discussions of dapps sending message through chat API. Is this part of scope? Doesn’t exist right now
There’s been requests from dapps
Andrea: Only describing current state of the app, not proposals
Oskar: Existing PR’s are about future proposals
Not sure if it’s been discussed or prioritized?
Barry: Is there a separate spec planned for dapp API use?
Oskar: Issue with problem discussion > New PR
Oskar: Corresponding issue in the spec for feature request
Anything else missing?

Mentions

https://github.com/status-im/specs/pull/105
Eric: Doing autocompletion. Will finish spec after
Serving notifications will need to be completed
Will change what’s left to do
Can this be merged as DRAFT
Eric: Will clean up copy right and stuff today
Oskar: Does current spec explain what is live?
Eric: Yes, status-go returns mention, client has to read it

Notifications

https://github.com/status-im/specs/pull/104
Had a few comments from Oskar
Eric: Need to review. Giving too much information about specifics of what Status does in Android client
Will also be a Draft handling of notifications by Status-go needs to be addressed
Specific signals for notifications; will be simpler for clients to implement notifications + more stable
Same messages as Status-react and interpreting to show notifications. Update would include signals. Allows user settings for what should be notified. Client would only need to got listen

These were Open PR’s still a bunch of issues, 18, plenty are quite old as well. Specifically 2 need more discussion.

#

https://github.com/status-im/specs/issues/116

Samuel: Integrating Waku into Status specs. Noticed a lot of EIPs referenced in 8 eip document. With Waku, we have specifications analogous to certain eips with regards to whisper. Not sure if they have a home in eip doocument. If they did, should document be renamed. They wouldn’t strictly be EIPs. Do we want to include these references? Not a major issue
Oskar: eips and bips; not clear if it’s double and what the use is
Oskar: curious others’ thoughts on existig spec and how much double it is.
Samuel: Same… Currently acts as reference place. Compilation seems useful. Marked for discussion open to opinions.
Pascal: Does anyone else want to add
Oskar: Coming from Embark team, how useful are specs to use as a reference, what would make it maximally useful?
Pascal: This particular spec or in general
Oskar: This specific spec
Samuel: Issue is open. Welcome to comment
Iuri: In general specs for sure help. Specs are well-done and wellwritten, better than reverse engineering code. Need to get back on this specific specs.

#

https://github.com/status-im/specs/issues/115

Dean: Not sure if this issue should be in this repository
Samuel: Should be in Vac
Dean: yes
Samuel: examples are specific to status specs. Maybe replicate in Vac
Samuel: have to check if there’s heavy use in Vac; definitely in status im
Samuel: in references on the issue, gives method for phrasing. If there’s is concensus on format; implement change. Implement in our documention on how to write specs
Oskar: Styleguides for language, add to read me there. If it turns into a recommendation doc. For now add to read me
Samuel: Reference at the bottom, nothing else to say

#

https://github.com/status-im/specs/issues/69

Agreed on protocol specs changes
Send mime-type
Send messages through Whisper. Easy part
During implementation discovered that pow is too high for images of reasonable size. Sending 200kb image would take 20-25 seconds, not even on mobile
Investigation on impact. Many small chat messages (in size, 500 characters). Sending bigger messages makes a difference. Sending 200kb messages. Concern is spam. There is no difference between spamming with many messages (most disruptive). Lower proof of work is easier. Rate limiting in place, Jakub can doubecheck config. Limit by message not by size. Do we want to go ahead for the lower proof of work?
Benefits: Less CPU intensive
Drawbacks: Spam cluster becomes easier (differentite between chat messages and size messages). Consuming more of users bandwidth can be impacted by latter

Oskar: Can size of messages be taken into account.
Andrea: Can keep a tally
Oskar: What’s the timeline
Andrea: Andrey polishing up UI
Ready. 1:1 and private group chats
Samuel: Change in implementation for POW required for sendin messages. Over 50000 bytes. Should that be in specifications
Andrea: Yes. Because we can’t lower POW for every message, other clients will discard it. If higher than x bytes use lower POW. Older clients would not support images. That needs to be reflected in spec. Similar to whether we would change POW
Samuel: Added this in draft. not sure if it needs to be taken out. Continue outside of this call
Andrea: Yes, let’s take offline

Any future spec proposals that anyone wants to discuss?
Notifications on iOS
Any thoughts?

Michael: Notifications oppt-in concerned. Other party on Android or iOS. Other person would also have to agree to this. Could be a vector for profiling.
Eric: Relevant, not the only issue. UX would be bad. Users with wonder why they would only get notifications for some, not other chats
If we delegate to centralized server
What would change.
Depends on direction. Send through Whisper, notification could filter? Issue with both parties having to agree, was in case of key exchange. V2 would be use of intermediate server. Sender would use Whisper. Android wouldn’t need to have libraries to communicate directly with Firebase
Andrea: Directly exchanging notification token through contact request. Unconventional. Token is meant to be a secred. I trust user, so send token. Same token send to multiple tokens. Alternative, central server. Wouldn’t trust this server. It would need to have access to server. Maybe build on top of Waku of Whisper. Better to follow aps like Signal. Save token on trusted server. Who controls server, Status at the beginning.
Oskar: What’s difference in terms of retention?
Hester: Unknown, need to check difference when Android is out
Eric: Waking up from notifications?
For notification service to work without knowledge of keys. With Waku, check topics, send background notification for topics you’re interested in. If there’s not too much topic collision. When you wake up the app there might be messages to read. If we don’t want to rely on the sender to notify notification server
Dean: App refresh, non–deterministic
Eric: Less reliable. Heuristics unknown