Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    f00bar
    @f00bar
    @tgerring It's a trade off - security vs adoption
    my sense is that if there are really popular blockchain apps built in real-life their users will be using a light web client
    Taylor Gerring
    @tgerring
    yes of course, but does that mean the light client MUST connect to some known SPV server? i think not
    i think the better alternative would be to connect to a small number of peers and maintain the P2P-like network
    that's the difference in approach between Bitcoin SPV and Ethereum light-client
    Péter Szilágyi
    @karalabe
    There isn't anything stopping you from creating an RPC based app (see http://syng.io/)
    But that's already doable even now
    We're aiming to bring the full capability of an Ethereum node into a mobile app
    f00bar
    @f00bar
    I see
    f00bar
    @f00bar
    well I have a question about the new RPC
    eth_accounts, eth_sendTransaction and eth_sign will be supported for backwards compatibility but will eventually be removed in the future ?
    @karalabe how would that affect web3 light JS web clients that are using a transaction signer and backend server geth node (provider) ?
    Péter Szilágyi
    @karalabe
    the goal is to gradually transition to geth becoming only a relay into the network and not do its own key handling
    this will allow external applciation to reuse the same geth process
    I don't know though when we would drop support for keys intenally though
    that's a bit further down the line
    I'm nto really familiar with web3 tbh
    @frozeman ^ ?
    f00bar
    @f00bar
    well I thought you could reuse the same geth process by using an external transaction signer
    Péter Szilágyi
    @karalabe
    That would be the idea yes
    mist already does it like that
    Though it's not that simple, becuse we have whisper and swarm too
    Péter Szilágyi
    @karalabe
    which are a bit more tied in with accounts
    nd identities
    f00bar
    @f00bar
    basically key pairs are managed client side and you can use a backend server-side geth process right now to receive signed transactions from the client light wallet
    so in a way I think that geth can be used as 'relay' into the network even right now
    and I'm afraid that if these eth_methods (eth_accounts, eth_sendTransaction and eth_sign) are removed I won't be able to use my JS light client
    : ))
    Péter Szilágyi
    @karalabe
    Indeed, but you still need to trust geth when you "read" the state of the network
    If it's a remote note, you have no way to validate that whatever it sends you is indeed the state
    f00bar
    @f00bar
    this is very disturbing because the app I'm building works with light clients on the web side and backend server geth node (as a proxy)
    I understand this is less than ideal from a decentralization perspective but that's ok for my service
    so now it looks like the new RPC changes that you make will defunc my JS light client since it relies on eth_accounts, eth_sendTransaction and eth_sign, etc...
    : ((
    shouldn't developer have the choice of choosing the choreography that best suits their needs? i.e fully decentralize and more of a client/server architecture
    Péter Szilágyi
    @karalabe
    Those won't be removed any time soon, that'a long term question
    Though I can't promise anything on that front, it's not really my decision
    I personally would probably leave it in as legacy support, even if we "encourage" outside account handlig
    f00bar
    @f00bar
    like I wouldn't even attempt to build whatever I'm building right now if I have to ask every single user of my service to download, install, configure and run a geth node
    : ))
    if you don't allow external transaction signers, this will greatly limit the appeal of using ethereum in my opinion
    Fabian Vogelsteller
    @frozeman
    The idea is to the key signing out to an external service or the dapp itself.
    As @karalabe says it will be there for the foreseeable future.
    f00bar
    @f00bar
    @frozeman what would that 'external service' look like ?
    Fabian Vogelsteller
    @frozeman
    If you do keysigning in your dapp you would use eth_sendRawTransaction
    A commandline tool for signing
    Or something. Or e. G. Mist
    f00bar
    @f00bar
    will I be able to use eth_sendRawTransaction from web3.js in the future ?