Environment aware Dapps for lowering adoption barriers (legacy proxy)

m0sem0se Member Posts: 10
While reading this thread http://forum.ethereum.org/discussion/comment/5842/ about accessing swarm/whisper based content from a regular browser, I started thinking if a network of “trusted” proxy could be build to make such content easy accessible and remove the need to installing something on every device for every ethereum-interaction.

Of course, it’s a bad idea, as centralised proxies operated by 3rd parties can never be fully trusted for serious business. But whats about Dapps (or aspects of Dapps) where easy accessibility is "more important” than full trust-less security?

One could argue, that you can use the old broken internet for that and don’t need a Dapp in that case. But whats about less critical aspects or sets of features of Dapps that for other features really need the secure environment?

For example, some sort of a decentralised-twitter, could heavily benefit from the trust-less environment, but why not be able to read this feeds from a untrusted environment? Sure there would be cases, where you better verify something you red in a trusted environment later, but I think there is still a lot to gain by providing this kind of legacy support.

I guess there soon will be Dapp-Projects anyway building there own application specific proxies to enable a easier or faster adoption. So wouldn’t it be healthier to have a generic approach in place, with which in mind Dapps could be built environment sensitive and use a common distributed proxy infrastructure? (the proxy implementation could, to slightly increase security have some sort of a reputation system or something,.. but I haven't really thougt deeply about options in that area yet)

Anyhow, Dapps could define what features they allow in a proxy environment or could even introduce proxy-env specific features. Like the twitter-dapp in the example before, could let you write less-trusted-posts (which are marked as such) via. a proxy and later on when you have access to your secure environment (eth-client) you could change them to trusted-posts by confirming there validity.

Some sort of a “you can’t really trust me” disclaimer (with a good simple explanation) for the proxy, the labelling as less-trusted/not-verified of stuff posted in this matter and showing the proxy-disabled features of Dapps could even educate the unaware Web2.0 user when stumbling upon it and motivate him to get in, in a secure (eth-client download & install) way so he have all the features and his posts appear with a trusted-status as well.

I think this way we could be more inclusive with novice and technically less experienced people.

Telling someone he first needs to download and install a pice of software to to participate (at all) in something new that looks and sounds a lot like regular webapps to him, is difficult and unlikely to be successful. Ok, you could do a better job on explaining the technical background and security implications, why it would be so important to not use a browser and a regular hosted webapp, but I guess you’ll loos a lot of people in that conversation.

Why not make a effort to let everyone participate in a easy (non-paradigm-shifting) way up to a degree where security really starts to matters?

When technically less experienced people could start discover limited portions of the ethereum network & dapps first and then softly get hints at certain point that there were even more useful option in this Dapp when used with a real client, after some time when this person starts feeling there's a real benefit to it, he will be more likely to invest his time in the, for him pain full, task of installing a new software and get it running. (Even then, will he be able to install the client at his workplace, where he occasional has time surf the net? no, probably not - so in this context this kind of legacy-adapter could be useful as well.)

Another aspect I think a common proxy infrastructure could be useful in is the integration of ethereum based contents and links in to the legacy Web-Platforms for there remaining time of dominance. So you could post “links” to public ethereum content on classic-facebook, reddit and so on. This way we could involve much more people who haven't decided to use or haven’t even heard of ethereum early.

For now this is just a bunch of toughs I came up with thinking about the abstract points in the post linked above. First I would care to hear what others think,.. if we could benefit from something like that. If there is a common interest, I'm happy to go a bit deeper and start develop this idea together with the community and then may even start actually developing xD


  • TechnologovTechnologov Member Posts: 102 ✭✭
    How about browser plugins? i.e. Chrome plugin + FireFox plugin ? Will it be good ? (the plugins can be hosted on the centralized ethereum.org website)
  • m0sem0se Member Posts: 10
    Thanks for the suggestion Technologov! I think plugins could even be used in a more decentral way. I can imagen browser-plugins which implement swarm and whisper. I'm not so sure about full blockchain functionality in plugins, but I could imagen solutions like Electrum-Wallet, where you have some full-node servers and the plugin would just handling the creation and signing of transactions. (although I'm not so sure plugins are a elegant approach,.. since you still have to install something on your side,.. why not just install a full client in this case?)

    My thoughts were more going towards a Architecture in which Dapps could be built to additionally support a classical web environment in a limited but smart way.

    I'm talking about the situations where you ask "can I use your Internet to check something" or a Internet-Coffe and you have no clue what environment your will ending up with (Maybe a old WinXP with only IE as Browser). But the lowest common denominator will still be the ability to load a HTML+JS document from a Webserver and display it.

    Dapps could be built in a way that they are aware and can adapt to this different environments. When they run in a full client and have access to the JS-Ethereum-Binding they run unrestricted, but when they find them self loaded throw some sort of proxy, they could start behaving in a different (save) way.

    This way we could use ethereum based dapps earlier for stuff that otherwise wouldn't make sense because of a lack of adoption.

    A simple example, if would like to have my blog in a dapp for some nice eth-based feature I came up with, I still probably wouldn't do it, because I would loos moste of my readers that way (as they don't use ethereum yet).

    If I could put my blog in a dapp and have fun with my eth-stuff but still could make the majority of the content available for the average web user, I would be much more likely to do it.
  • vaXvaX Austin, TXMember Posts: 78 ✭✭✭
    @m0se you'll still be able to interact with http:// through ☰therBrowser.

    VVe're formulating 'print-to-http' buttons into our ÐΔ♇♇'s. These 'instances' will simply serve as quasi-dynamic looking-glasses, with little to no actual ☰thereal fvnctionality.

    These 'ϟlivers ov ☰thereum' are to be 'printed out' upon an intervally shifting, distributed network ov ϟtealthy ϟervers. These snapshots will marginally re:Present what's been happening over in eth://land. The experience of our 'prints' will feel very much like visiting a still-life in a museum.. verses one actually hanging out and co-creating with the Δrtists in their studios.

    An eth:// 'browser extension' running in chrome, or firefox, or any other tcp/ip conduit, is logically nonsensical at this point. In a post '♇rotocol VVar' world, things may very well be quite different.

    eth:// is our Ð☰∇ environment, ♇latform, 门etvverk, and ♇r0t0c0L ov choice. If there is even to be such a thing as a 'hybrid://ge' built between these two realms (http/eth) - then this 'print-to-http' functionality is as close (at this point in time) as vve wish to get.

    VVelcvm to thee ☰://volution - 门ode Thine☾ellf

  • vaXvaX Austin, TXMember Posts: 78 ✭✭✭
    /\lso, with re:gvard to plugging-in to the old world Operating $ystem. 3y3 like the i-dia ov (((being))) abel to ☰mancipate http $laves:

  • m0sem0se Member Posts: 10
    @vaX I was already assuming that the ☰therBrowser will do regular HTTP as well, this isn't the tricky bit. This print-to-http seems to be more the direction I think is interesting and still unclear (who is hosting this "print-outs"?).

    Another thing is Print-to-http sounds pretty static and "read-only" to me. I think there are lots of interaction features that could be provided to the legacy http system (where still moste people are) from a Dapp.

    Don't understand me wrong, I'm all for leaving this mess of "cloud" hosted http services behind me. I'm just thinking about ways to make it a more attractive to build stuff on it while we are starting to go in to this transition period.

    My concern is, that without some kind of a HTTP-Gateway-System a lot of stuff that could already be built on ethereum over this period, will probably still be build the old way because there won't be enough users in Etherland in the early.
    So for a lot of projects where security and a absolut trustless environment isn't the ultimate key feature of the app, will probably not be interested in building it in a "closed" environment where every user would need a special browser (even for the most trivial things).

    With some sort of a interactive http-gateway you could build a Dapp and present it to the general public in a convenient way, but still having the benefits of a trustless environment in the backend and can use this to encourage user to get a ☰therBrowser for having access to more advanced features and more security.

    I think this would make it a more positive experience for new users then a radical "either your in or your out"-policy.

    Or for who are you speaking, when you say "'print-to-http' functionality is as close (at this point in time) as vve wish to get."? Are you part of one of the ethereum implementation or are you just speaking for a specific Dapp you are building?

    I agree that plugins probably won't be build. The problem I see with the plugin-approach is, that there is probably to much effort to implement Eth+Swarm+Whisper in several Browser-Plugin APIs for not much benefit in deployment compared to a full blown ☰therBrowser. (But I'm not sure, maybe there is some unified way - I've never done browser plugin development).

    I can't say much to the OpenBazar discussion as I haven't looked in to the OB over all architecture yet.
  • FrodonomicsFrodonomics Member Posts: 14
    edited September 2014
    Interesting points... I think new users would like to see:

    - A test gateway where you could sign up with 2 dollars and start sending contracts to friends.

    - Honest disclaimers on your site warning ppl to be responsible.

    - A Facebook app to send micropayments: Ethertip.

    - A decentralized Twitter is a great idea and could be massive. I'd want to see 3 security settings: High, Medium and Low. You could explain to ppl what each setting means.

    - Allowing micropayments on a Twitter/Appleseed type system could be the future of buying and selling. Again, Beta could be in small amounts. Less than 5 dollars per transaction. That proves to users you have their safety in mind.

  • FrodonomicsFrodonomics Member Posts: 14
    My family and friends would need something like:

    - A test website that needs no software.

    - A Facebook app.

    - An easy to install smartphone app.

    - Step by step video guides

    - Constant reminders to be cautious and use high security protocols.

    - A first stage easy to dload dedicated browser with limited capability. i.e. Ethereum lite.

    - A second stage browser with more capabilities. And so on...

    Etherlite Etherbasic Etheradvanced...

    Those names aren't fancy but they tell users what they're getting.

    Tell them exactly how long it takes to dload and configure a browser. (It takes 90 seconds to install)

  • FrodonomicsFrodonomics Member Posts: 14
    edited September 2014
    I think you're right that there may have to be an interim period 2014-2016 where you are making compromises with the old net.

    You can just tell people what direction you're going in: decentralization, and tell them why: "Do you want your data stored by big institutions that are vulnerable to hacking and corruption?"

    Make specific apps: Ethermp3 for music, etherbook, ethertwitter clone...

    EVERYONE gets creeped out giving up data to the old net. No one likes this NSA BS.

    Remind them that you're just making these apps available for a test period, while everyone gets up to speed.

    You could limit transaction sizes, total wallet sizes and even time (app shuts after 30 days) then you are offered the next one...

    Make a clear step by step bridge and users will come..

    I don't understand a lot about everything you're doing. I hope that was useful.
Sign In or Register to comment.