
How to access Ethereum-based applications? - bleumi
https://medium.com/@bleumi/how-to-access-ethereum-based-applications-be460fe2f777
======
emre
[https://metamask.io/](https://metamask.io/)

~~~
spery
That's a pretty bad answer considering metamask instability. Having done a
simple project on ethereum, metamask was major pain, and I would like to skip
it next time.

~~~
mplewis
Can you tell us more about the trouble you ran into with Metamask?

~~~
spery
One of our use cases used factory pattern when creating contract instances.
You'd get contract address by subscribing to event from the blockchain. Issue
I ran into was that metamask would not get events from the blockchain even
though it should. There we're a lot of issues with the feature, some resolved,
some still not. Basically this issue: [https://github.com/MetaMask/metamask-
extension/issues/2393](https://github.com/MetaMask/metamask-
extension/issues/2393)

------
rthomas6
Python:

    
    
        from web3 import Web3, HTTPProvider
        
        web3 = Web3(HTTPProvider('http://localhost:8545')) #Assuming you're running your own ETH node
        your_eth_wallet_address = web3.eth.accounts[0] #Assuming you want to use your node's first wallet
        web3.eth.defaultAccount = your_eth_wallet_address
    
        dapp_contract = web3.eth.contract(contract_address)
    
        #Read data from the dapp or execute a function locally (No transaction cost):
        dapp_contract.call().function_name(*function_arguments)
    
        #Send an ETH transaction (Pay for gas, plus whatever this transaction does):
        dapp_contract.transact().function_name(*function_arguments)

------
callil
The UX for interacting with Ethereum apps is slowly improving. The most
interesting work going on in this space has to to with getting web3 available
on mobile devices which is starting to make dApps useful on the go. This might
lead to many more micropayment apps being developed. Best practices right now
are centered around using your phone to scan QR codes to quickly add payment
addresses.

Additionally, all these web3 providers who are developing browser based
solutions are trying to provide a psuedo app store to make their platforms
more useful.

Some examples I've been playing with lately are:

[https://status.im/](https://status.im/)

[https://www.cipherbrowser.com/](https://www.cipherbrowser.com/)

[https://www.omise.co/go](https://www.omise.co/go)

A competitor in this space is blockstack who is pushing the dApp model hard:
[https://blockstack.org](https://blockstack.org)

~~~
marknadal
Browsers now have the native Web Crypto API which makes doing fully P2P end to
end encrypted decentralized applications possible.

For instance, here is a demo of a social network dApp I built that is running
a distributed correctness test across many real world devices that are
updating character-by-character in realtime:
[https://youtu.be/C3akdQJs55E](https://youtu.be/C3akdQJs55E) (fully P2P and
encrypted!)

I know blockstack has been pushing this but they still require their own
browser. Meanwhile you can build apps like above as easily as 40 lines of code
and a few minutes, check out this interactive coding tutorial:
[https://scrimba.com/c/c2gBgt4](https://scrimba.com/c/c2gBgt4)

~~~
fenwick67
You're still relying on the central app-specific server for connecting peers
to each other, it's disingenuous to say it's "fully p2p".

~~~
marknadal
False, it is fully peer to peer. The browser, even with WebRTC, can't do full
P2P, but that isn't gun's fault, because if you run a NodeJS peer it can and
will be fully P2P. And you can you mix these together.

~~~
fenwick67
You're right that it's not gun's fault you can't do direct p2p in a browser, I
guess my point is that this is one reason why people keep making browser forks
and plugins

~~~
marknadal
Ahhh, thanks for clarifying. Good point. Yes, that is true, but my concern is
if we tie the dApp to strongly to these forks or plugins we also can only grow
the user base as fast as users who are willing to install and use these
alternatives - which I believe just shoots our own growth in the foot.

Instead, if we make it work out of the browser by default, then we can get
much better user adoption and then optionally ask users to opt into more
secure and reliable alternatives after they have already built trust with us
and been won over. Does that make sense? Thoughts?

