Browser Priorities Q1 into Q2

Browser
1

This is a twin post to the one on chat priorities, reflecting on the Browser team’s work in Q1 and selected items for Q2.

Top line: The browser team accomplished all of its goals in Q1, with the exception of one small issue (recently unblocked). :tada: In Q2, the team shifts towards being a “Core UI” swarm with a more general focus.

Priorities were recently discussed by the team in terms of impact x effort with the big picture goal being to prepare for a public launch. This leads to a greater emphasis on more core projects, such as onboarding and profile work.

Q1 in review

Work selected as must-haves

  • Sticker Market MVP
  • “Transaction signing issues” – to investigate 7212
  • Universal links can be opened from within status on Android
  • EIP1193 exposed via window.ethereumBeta [PR 7183]
  • Add support for eth_requestAccount (latest EIP1102 update)[PR 7183]
  • Manage web3 permissions (#5584)
  • Enable EIP1102 by default (#7113)
  • DApps w/ same host share localStorage / cookies (#6587)
  • “Open in iOS” or “Open in Android”
  • Ethereum URI scheme <— not completed

Work completed

  • Sticker Market MVP
  • “Transaction signing issues” – to investigate 7212
  • Universal links can be opened from within status on Android
  • EIP1193 exposed via window.ethereumBeta [PR 7183]
  • Add support for eth_requestAccount (latest EIP1102 update)[PR 7183]
  • Manage web3 permissions (#5584)
  • Enable EIP1102 by default (#7113)
  • DApps w/ same host share localStorage / cookies (#6587)
  • “Open in iOS” or “Open in Android”

PLUS lots of work to bring extensions out of alpha and improve the development environment; new & improved app navigation.

Q2 top items

Work selected as P0

  • Browser improvements:
    • Remove DApp list; link to DApp store
    • Add history on long press of bottom arrows
    • Move refresh/add X to address bar
    • Use favicons for DApp chat icons
  • New onboarding flow
  • Fix account recovery flow/reduce confusion about role of the password
  • Polish and ship Kyber extension with app
  • Polish and ship image sending extension with app
  • Hide extensions installation flow from release builds

Work that is nice-to-have

  • Extensions out of alpha
    • Security/modeling permissions—aim for designs complete in Q2
    • Error handling in development environment
  • Extensions installation and discovery—aim for designs complete in Q2
  • Sticker Market for creators—aim for designs complete in Q2
  • Support for network switching in the browser (thinking of xDAI usage)

To be discussed/prioritized

  • Pieces of profile work, e.g. Settings: Privacy and security, Notifications, Advanced
    • Will coordinate between chat + browser teams to get coverage across the full scope of the profile work.
7 Likes
2

Sweet! I’ll just chime in on one reoccurring item I’ve noticed, and that’s image sharing built as an extension. To kick things off, I’ve created designs for image sharing in chat regardless of how it’s built :point_right: https://www.figma.com/file/aS1ct66VQ6V0cio7vSqS8UoG/Chat?node-id=4175%3A23237
I’m leaning towards native similar to how we made stickers since mostly it’s such an integral chat feature and I imagine people will like to create their own image extensions that build on top of the native image sharing UX we provide.
Anyway, it would be cool if we had a brief look at the designs first if they are possible to create with extensions alone?

Not quite yet, I’m missing the entire login flow :slight_smile:

3 Likes
3

Hey @maciej ! Very nice design!!

Just added a bunch of comments.
A number of things can’t be done currently using extensions. But don’t despair! I don’t see that they can’t be implemented. And most things are definitely interesting for extensions in general.

2 Likes
4

Seems perfect for BUIDLWeek!

5

Something multiple teams inside and out of Status have been requesting for sometime now is exposing more of the Status API to DApps. Being able to send a message to a channel or another user and display messages from channels and messages within a DApp seems like a key differentiator between the Status browser and other web3 browsers. Is this on the roadmap?

2 Likes
6

I do remember the request for a DApp to be able to send push notifications from multiple parties, which was very interesting to us. It was more or less shut down because, I think, some concern over our use of Firebase to send PNs?

But there were several conversations happening on the topic of DApps being able to message over Whisper. I agree, it would be a unique and powerful value for Status to offer while DApps are still primarily web-based.

At the time, I heard more constraints and blockers than enthusiasm from our side.

@igor @andrey maybe you guys recall some context?

It’s not on the roadmap for the above reasons, but also because it doesn’t strike me as the kind of tablestakes feature we need to have for adoption (which is now my focus).

7

I would be interested to see some writeup on this we can reference for our own knowledge and when people ask us.

Just to be clear, I’m taking about exposing an api to the browser like status.sendMessage(channel, message)

Upon which the status browser will pop up a dialog asking the user if they want to allow DApp X to send the message.

1 Like
8

+1 for allowing DApps to send messages.

More concrete, I’d love to see this onboarding proposition come to life:

Use Status Chat to familiarize yourself with a decentralized/cryptocurrency world, no crypto required.

The flow would look something like this:

  1. Visit learncrypto.com in any browser
  2. Create an ‘Account’ with Status
  3. Open learncrypto.com in Status Browser
  4. Allow learncrypto.com to send you messages
  5. A conversational coach gives you little opt-in assignments to make transactions, use DApps, vote, read, watch

A ‘Cryptocoach’ can serve as an interactive education layer on top of Status using the messenger as a bot (yes, I said it:blush:).

reference: https://www.notion.so/CryptoCoach-Design-Specification-ffa1a4797186455b93decd9b4489026b
I may be biased :neutral_face:

9

ping @adam, we are working on exposing Status protocol APIs via RPC now, and he is a great contact point.