Status Core Dev Call #31 - June 01, 2020

Status Core Dev Call #31 - June 01, 2020

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

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

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


  1. Agenda setting (~5)
  2. Announcements (~5)
  3. Review previous actions (~5)
  4. Specs review > open PR’s for Discussion (~20`)
    a. Keycard
    b. DApp browser API usage spec
    c. Mentions
    d. Notifications (Android) - Draft
  5. Expected changes/proposals (~15`)
  6. Images support and network spamming (10’)
  7. App distribution / contingency getting kicked out of App store (10’)
  8. AOB (~5`)


1. Agenda

Nothing to add

2. Announcements

No announcements

3. Previous actions

4. Specs review

a. Keycard

Needs input from Roman, skipped.

b. DApp browser API usage spec
Vitaliy is not here. Skipped.

c. Mentions

Two PR’s, already pushed.

d. Notifications (Android) - Draft

Oskar will review the PRs from Eric.

5. Expected changes proposals

Notifications on iOS is one proposal. There’s different options but we have to wait to discuss it. Andrey will post on Discuss

6. Images support and network spamming

  • Jakub: PoW lowered to 50bytes. Easier to spam? Not sure of message size is considered
  • Oskar: Haven’t relied on PoW as mitigation for spam.
  • Jakub: Take more variables into account. Also hasn’t been tested
  • Andrea: Rate limiting kind of works. Was checking for spam. Seems to be some rate limiting on place.
  • Jakub: Take into account size and channels
  • Jakub: Andrea are you ok working on it?
  • Andrea: Yes fine
  • Jakub: Will open issue

7. App distribution / contingency getting kicked out of App store

  • Hester: Looking for all possible options to handle this scenario
  • Options:
    • Release without browser on iOS
    • Depending on problem, remove some dapps?
      • Would be weird. How to select?
    • Sideloading. Not super realistic
    • Release through Testflight
    • Remove front page dapps entry
    • Contract calls to e.g. Uniswap through Chat API
      • Implies custom integrations for every dapp
    • Amazon resolves this by purchasing through webbrowser to buy
    • Question of extend of support
  • Hester: Need to better understand what dapps or functionality is most impacted if we cannot offer these through the browser?
  • Oskar: Telegram and Wechat are good examples to look at
  • Hester: Corey might have some notes about this to start a Discourse discussion. Hester will follow up and else document above input on Discuss


(i) Creating an interface for displaying third-party apps, extensions, or plug-ins similar to the App Store or as a general-interest collection.

(ii) Monetizing built-in capabilities provided by the hardware or operating system, such as Push Notifications, the camera, or the gyroscope; or Apple services, such as Apple Music access or iCloud storage.

8 . Any Other Business

  • Jakub: Talking about pending transactions and getting those into the app. There doesn’t seem to be a good solution. Infura doesn’t provide this status. It seems like the only solution would be for us to build another centralized solution for indexing the status of transactions. @Samuel have you found another way of doing this or would we have to make our own solution?

    • Samuel: The only other thing is that we create - solution that would solve a number of things like reliance on 3rd parties for access to Ethereum nodes.- Essentially to build an incentive mechanism to provide the data we want to consume. Not Status specific, but some sort of broker network for transmitting data in exchange for a fee.
    • Preliminary stage. Because of a number of factors, such as ‘How can you trust data you’re getting is true?’ ‘How can you ensure that calls are properly logged?’. If incentivized, the Presumption is that some sort of token value would be used to incentivize data brokers.
    • The other part is, if you can’t solve those issues, you still need node discovery. You’d be searching for peers, you wouldn’t want to be pointing to a specific node. This problem would probably be solved easily if Infura would offer pending transactions, they don’t. Falling back to infura crux. Hard problem.
    • Next step: Opening document to collect opinions and avoid overlap. Separate issue to pending transactions. Because it would be an additional protocol alongside the Ethereum network. Autonomous, trustless mechanism to ensure data accuracy and processing and charging of calls.
    • Oskar: Somewhat what Dmitry is working on with Dagger as well as Nimbus light client. A lot of prior and current work going on. There are some discussions on Discuss on ultralight client. Also an issue in Status-go on lightclient and potential use of ‘’?node’ to look into
    • Samuel: Will ping for resources
    • Barry: Worth noting that relying on Infura, not aligned with principles of preserving privacy. Infura as a service is costly and it’s not known what logs they keep and how they are used. IP-addressed and metadata around who sends a transaction, whos reading, what they’re reading can be logged. Infura is a black box. All privacy preserving features can be nullified by relying on Infura.
    • Oskar: Absolutely. Was a top priority for a while to have a node running on device. Got replaced by focus on SNT utility and user acquisition. To move this forward it would have to be a priority for core again. Could do more, depends on priorities for Core. A lot of opportunities including low hanging fruits
    • Barry: The other thing is that running lightclient is ambitious in itself, maybe other approaches could work. For example, fetching data through mix net (?), rely on remote node for heavy lifting, but preserve privacy.
    • Cammellos: Talking about pending transactions. Do we know what other wallets do? As it seems to be so technically difficult. Amount of work seems to outweigh benefit. Is it worth investigating further? There are two issues, centralization and reliance on Infura, something we have dealth with in the past, and is it meaningful to persue any technical solution where effort outweighs benefit.
    • Eric: Walleth is using Etherscan I think
    • Samuel: Equivalent, to Infura, basically just switching. From what’s I’ve read I don’t think anybody that has an active product has implemented a solution that doesn’t rely on somebody running nodes and is basically indexing the data in there. Problem is for inbound transactions, outbound is simpler. Not aware of existing solutions. Happy to know if anyone knows different solutions
    • Jakub: Incoming might not be essential. If it’s only to have a spinner showing when you get a transaction. Could be centralized for a nicer UI which can be an optional solution. If it doesn’t work you don’t get a spinner, but you don’t lose essentual functionality. Doesn’t seem like it should be viewed as a problem.
    • Samuel: Basically agree, but problem is that this is symptomatic of larger issue we have
  • Continue with smaller group. Eric, Samuel, Jakub

    • Samuel: Looking to discuss something to solve now. And long-term solution
    • Eric: Does anyone know more about Dagger? Searched on Discord doesn’t seem to be any documentation beyodn a joke about a whitepaper
    • Eric: Regarding a way to exchange token for node incentivization. Perfect use case for Raiden, just on Mainnet, for node incentivization. When we release onboarding pack, it could be opportunity to open channel with a nide from Status or others in order to pay for queries
  • Closing meeting

Action Items

[ ] Define process around pinning new stickers (needs owner)
[ ] Barry: Add issue + PR for indexing proposal
[ ] Hester: Follow up with Roman on issues Keycard PR
[ ] Eric: Merge Notifications PR as DRAFT
[ ] Jakub: Create issue on rate limiting and other variables to prevent network spamming
[ ] Hester: Follow up with Corey on contingency plan in case of App store ban
[ ] Samuel: Ping Oskar for resources on incentive mechanism for data sharing