Get Status

Status Core Dev Call #30 - May 18, 2020

Status Core Dev Call #30 - 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  

3. Review previous actions

4. Specs review > open PR’s for Discussion

5.  Expected changes/proposals

  • Notifications on iOS

6. AOB


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

Specs review

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

  • Add spec for IPFS gateway for Sticker Pack
    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


Dapp browser API

  • 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?


  • 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


  • 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.


  • 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.

Removal of pronouns

  • 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


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

Download Status

Get Status