Extensions to enhance old web


aka Greasemonkey 3.0

Kudos to @rachel for the original idea, based on https://ethereum-magicians.org/t/dapplets-rethinking-dapp-architecture-for-better-adoption-and-security/2799

What if we could plug some ethereum/contacts goodness to any regular website?
Like rewarding any content creator, à la Brave?
Except this is controlled by an extension, not hardcoded and owned by a company.

By leveraging extension features we can let developer come up with fancy ideas and let users decide when it make sense to enhance their favourite website.
Brave Rewards itself could be available in Status, via an extension.

{:url      "https://twitter.com"
 :target   "id"                  ;; some DOM id or expression
 :view     [some-view]           ;; Some view that will be injected
 :on-event {:type  :on-click     ;; OR a DOM event to listen to
            :value [some-event]}

You can then inject some extensions designed logic in any regular Web 2.0 website and seamlessly hook Wb3.0 behavior.
The last missing bit is what to do then? How do you extract relevant information so that you can react accordingly depending on potentially any website? Somehow data must be extracted from a site and made available to the extension - wether from URL, page content, …

How do you see this being used?


Hello guys!
Hello @julien & @rachel!

After the dapplets idea was implemented as an initial PoC on ETHParis I am collecting feedback and aligning my roadmap to the related work being made great by teams around me.

Is there more details I can read about your proposal, @rachel?
May be we could join our efforts to make it happen?


I think is a great idea. There is a difficulty in implementing it: how to detect the rightful account owner of some id in some social media?
I think we should not think about putting this in a smart contract, because privacy; and needs oracle.

Maybe if user put somewhere in their twitter account profile:

  • status://user.stateofus.eth (and load from ens)
  • status://0x04d8be51670c96c2c124075b3295410b3e38fe8e20376f7916f17c9b984d08fda2d42425b409629c57ac845dc2bfba8ef9de45f8172042a9e0c877ffd6355fb719 (and derive address from it);
  • status://0x3D597789ea16054a084ac84ce87F50df9198F415 .

Using the information in the website, the extension could recognize it and tip to address. It don’t fixes the privacy problem, but using blockchain is worst as it gets “forever” persisted in history, but it simplifies and removes the need of a connecting contract.

The “status-api” injected js object in the dapp could also allow to webmaster configure the tipping address, so any dapp (or webapp) can set the tipping address they choose.

The tipping option would only be available if Status find a tipping address.
User will need to open twitter or whatever inside of Status for tipping, but for desktop browser an extension could be made, a safe model could be Status Remote (Identity, Authorization)


Hey @ethernian ! The idea here is to leverage extensions syntax which is very Status specific.
Not quite sure what we could standardized.

Any insights on what could be common between various implementations?


I think at least the link between Dapp and Wallet should be standardized, whatever it is. It look’s like what WalletConnect does.

What the script you mentioned is good for? Can I read more about it?


As Status is both a DApp browser and a wallet (also integrates with hardware wallet using Keycard API) it’s not something we are currently actively considering.


The syntax I was referring to is Status extensions