Personal Volunteer Computing

Total Page:16

File Type:pdf, Size:1020Kb

Personal Volunteer Computing Personal Volunteer Computing Erick Lavoie Advisor: Prof. Laurie Hendren School of Computer Science McGill University This dissertation is submitted for the degree of Doctor of Philosophy December 2019 I dedicate this thesis to everyone world-wide that is actively finding ways of living that increase the health of their natural and social environments. May the field of computing be part of and amplify those initiatives. Declaration I hereby declare that except where specific reference is made to the work of others, the contents of this dissertation are original and have not been submitted in whole or in part for consideration for any other degree or qualification in this, or any other university. This dissertation is my own work and contains nothing which is the outcome of work done in collaboration with others, except as specified in the text, acknowledgements, and the following three papers, whose material has been expanded. Personal Volunteer Computing, published at Computing Frontier 2019 and co-authored with Laurie Hendren, is a summarized version of the Background (Chapter 2), Volunteering Scenarios on a Local Wi-Fi Network (Section 6.2), and Future Research Directions (Sec- tion 8.1). For this paper, I articulated the socio-technical analysis framework, performed literature reviews, did the experiments, and generated new ideas for future directions. Laurie helped improve the flow of ideas, focus the argument on the essentials, suggested the mobile experiments, and revise the methodology and analysis to make sure it was sound. Pando: Personal Volunteer Computing in Browsers, published at Middleware 2019, co-authored with Laurie Hendren, Frederic Desprez, and Miguel Correia, is a summarized version of the Design of Pando (Chapter 3), the Pull-Stream Design Pattern (Section 4.1), the StreamLender presentation (Section 4.4), the Applications (Chapter 5), and the Volunteering Scenarios on a Wide Area Network (Section 6.3). For this paper, I designed and implemented Pando in JavaScript, I articulated the core properties of the programming model, I suggested a notation to describe the algorithms, I described the existing Pull-Stream Design pattern and its properties, I implemented all applications (except for the first version of Raytracer that was done by Umair Khan), and I performed and described all experiments on the Grid5000 and PlanetLab testbeds. Laurie helped improve the clarity of descriptions, the flow of the text, the use of examples, suggested categories of applications to implement, and helped structure the argument presentations over the various revisions of this paper. Fred and Miguel suggested references to existing work in distributed systems and helped improve the flow and quality of writings. Genet: A Quickly Scalable Fat-Tree Overlay for Personal Volunteer Computing using WebRTC, published at SASO 2019 and co-authored with Laurie Hendren, Frederic Desprez, vi and Miguel Correia, is a summarized version of Genet: Quickly Scalable Fat-Tree Overlay for WebRTC (Chapter 7). For this paper, I designed the overlay, implemented it in JavaScript for Pando, implemented the simulation tool for assessing the balance of trees as well as the webrtc-connectivity-testing tool for testing the connectivity of WebRTC between groups of participants, I performed all experiments, generated figures, did a first analysis of the results, and performed a literature review of existing work. Fred and Miguel suggested related works and Laurie, Fred, and Miguel helped revise the writings. Erick Lavoie December 2019 Acknowledgements First and foremost, thanks to Quebec and Canadian tax payers who funded most of my research, either through scholarships, grants, or subsidized education fees. I would never have had the financial means to do it otherwise and this funding provided me with much needed free time to articulate the ideas in this dissertation. It is my hope that those ideas will provide direct and indirect benefits that are at least commensurate with the resources that supported my education and research training. Thanks also to the various funding bodies, such as the National Science and Engineering Research Council (NSERC) of Canada, and Fond de Recherche du Quebec – Nature et Technologies (FRQNT) for managing those funds so they can reach researchers and maintain a lively and world-class intellectual environment. While my funding came from those organisms, any opinions, findings, and conclusions or recommendations expressed in this dissertation do not necessarily reflect the views of NSERC or FRQNT. In a similar spirit and to ensure the French government continues to fund common infrastructure for research, I acknowledge that some experiments presented in this paper were carried out using the Grid’5000 testbed, supported by a scientific interest group hosted by Inria and including CNRS, RENATER and several Universities as well as other organizations (see https://www.grid5000.fr). Thanks to Umair Khan for creating the initial version of the Raytracing application example described in Section 3.1 and Section 5.1.2. Umair emailed me in July 2017, after having just graduated from Delhi Technological University, wanting to contribute to some of the research projects we were doing at McGill. His feedback and thirst for learning have helped improve Pando, and his volunteering initiatives have fuelled my motivation to continue working on the project. Thanks to the many members of the McLab team at McGill throughout the years. In particular, thanks to Faiz Khan, Sujay Kathrotia, and Vincent Foley-Bourgon for their collaboration on our first JavaScript benchmarking paper that established the performance feasability of Pando. Thanks to Faiz additionally for properly setting me on the "dating scene", which set things in motions that eventually led me to meeting the love of my life. Thanks to David Herrera and Hanfeng Chen for our collaboration, and much of the groundwork, on the second JavaScript benchmarking paper that showed the performance opportunity on mobile viii devices was even more interesting that we previously thought. And thanks to everyone else in the team over the years that had the patience to listen to my ideas (and rants!) in lab presentation and informal discussions, these interactions have been key to turns the seeds of ideas in sprouts. Thanks also for all the supporting staff at McGill who manage the administrative affairs and helped ensure our rooms were clean. It is quite easy to forget that lively intellectual environments depend much also on well functioning bureaucracies and well-tended physical spaces. Many of them have duly performed their work even through the challenging budget cuts that we collectively experienced in the mid 2010s. Thanks to Miguel Pupo Correia in providing helpful and timely feedback on papers we co-authored over the years, as well as the welcoming environment when I visited Lisbon. While Pando’s design evolved in a way that eventually did not require the improved version of the Kademlia design we published together, the work we did helped me understand the drawbacks in complexity of global persistent peer-to-peer platforms that prompted the articulation of personal volunteer computing and the later designs. Thanks to many colleagues and friends at INRIA in Grenoble. In particular, thanks to Frédéric Desprez, Imma Presseguer, and the rest of the CORSE team at INRIA for providing a welcoming environment, first in hosting me for an internship in the summer of 2016, and then providing a working space and company during much of the writing process of this dissertation. Thanks to Antoine Hokayem for having taught me to put the technical contributions and core ideas ahead of my personal agenda in research papers, I am convinced it has made a difference in getting the latest version of the Personal Volunteer Computing paper accepted. Thanks also to Fabian, François, George, Antoine and everyone else for passing by regularly in my office and pulling me for beers and social activities, this was a much needed relief. I hope we will all be done with our dissertations soon! And thanks to the NanoD and OneAngstrom teams on the first floor, for their participation in the smartphone experiments of this dissertation and their company in sharing meals, breaks, "publishing" cookies and cakes. Your presence has made my work environment much more lively. Thanks to many people from the Secure Scuttlebutt (SSB) evolving community. Thanks to Dominic Tarr who shared his contagious curiosity, insights, and for quickly "pulling" me in the community by trusting me with administrator privileges on the pull-stream organization as soon as I had produced new useful modules. Thanks to Bob Haugen for revising a rejected version of the Personal Volunteer Computing paper, which has helped keep my motivation level high at times when I had trouble finding the right audience and adequately communicating the insights behind the approach. Thanks to Alexander Cobleigh, aka ’cblgh’, for voluntarily revising and commenting on a draft of this dissertation: knowing someone ix else than my advisor and review committee has read my thesis voluntarily made the entire effort worthwhile! Thanks to Daan, the only SSB friend I can regularly meet in Grenoble for beers and Lego. Thanks to the rest of the community, too numerous to mention, for fostering a "radical" intellectual environment that inspired the articulation of the personal volunteer computing paradigm. Thanks to the Soulakins, an informal group of friends in Grenoble and elsewhere in Europe sharing
Recommended publications
  • Pangea Jurisdiction and Pangea Arbitration Token (PAT)
    Pangea Jurisdiction and Pangea Arbitration Token (PAT) The Internet of Sovereignty Susanne Tarkowski Tempelhof, Eliott Teissonniere James Fennell Tempelhof and Dana Edwards Bitnation, Planet Earth, April 2017 Pangea Jurisdiction and Pangea Arbitration Token (PAT) The Internet of Sovereignty Susanne Tarkowski Tempelhof, Eliott Teissonniere, James Fennell Tempelhof and Dana Edwards Bitnation, Planet Earth, April 2017 <abstract_ The Pangea software is a Decentralized Opt-In Jurisdiction where Citizens can conduct peer- to-peer arbitration and create Nations. Pangea uses the Panthalassa mesh, which is built using Secure Scuttlebutt (SSB) and Interplanetary File System (IPFS) protocols. This enables Pangea to be highly resilient and secure, conferring resistance to emergent threats such as high- performance quantum cryptography. Pangea is blockchain agnostic but uses the Ethereum blockchain for the time being. In the future, other chains such as Bitcoin, EOS and Tezos can be integrated with Pangea. The Pangea Arbitration Token (PAT) is an ERC20 compatible in-app token for the Pangea Jurisdiction. The PAT token rewards good reputation and is issued on Pangea when Citizens accumulate non-tradable reputation tokens through creating a contract, successfully completing a contract or resolving a dispute attached to a contract. PAT is an algorithmic reputation token, an arbitration currency based on performance rather than purchasing power, popularity or attention. The distribution mechanism for PAT tokens on Pangea is an autonomous agent, Lucy, which will initially launch on Ethereum as a smart contract. This mechanism is blockchain agnostic and can be ported to any viable smart contract platform. An oracle created by Bitnation will help to facilitate this (semi-) autonomous distribution mechanism in a decentralized and secure fashion.
    [Show full text]
  • Uila Supported Apps
    Uila Supported Applications and Protocols updated Oct 2020 Application/Protocol Name Full Description 01net.com 01net website, a French high-tech news site. 050 plus is a Japanese embedded smartphone application dedicated to 050 plus audio-conferencing. 0zz0.com 0zz0 is an online solution to store, send and share files 10050.net China Railcom group web portal. This protocol plug-in classifies the http traffic to the host 10086.cn. It also 10086.cn classifies the ssl traffic to the Common Name 10086.cn. 104.com Web site dedicated to job research. 1111.com.tw Website dedicated to job research in Taiwan. 114la.com Chinese web portal operated by YLMF Computer Technology Co. Chinese cloud storing system of the 115 website. It is operated by YLMF 115.com Computer Technology Co. 118114.cn Chinese booking and reservation portal. 11st.co.kr Korean shopping website 11st. It is operated by SK Planet Co. 1337x.org Bittorrent tracker search engine 139mail 139mail is a chinese webmail powered by China Mobile. 15min.lt Lithuanian news portal Chinese web portal 163. It is operated by NetEase, a company which 163.com pioneered the development of Internet in China. 17173.com Website distributing Chinese games. 17u.com Chinese online travel booking website. 20 minutes is a free, daily newspaper available in France, Spain and 20minutes Switzerland. This plugin classifies websites. 24h.com.vn Vietnamese news portal 24ora.com Aruban news portal 24sata.hr Croatian news portal 24SevenOffice 24SevenOffice is a web-based Enterprise resource planning (ERP) systems. 24ur.com Slovenian news portal 2ch.net Japanese adult videos web site 2Shared 2shared is an online space for sharing and storage.
    [Show full text]
  • The New England College of Optometry Peer to Peer (P2P) Policy
    The New England College of Optometry Peer To Peer (P2P) Policy Created in Compliance with the Higher Education Opportunity Act (HEOA) Peer-to-Peer File Sharing Requirements Overview: Peer-to-peer (P2P) file sharing applications are used to connect a computer directly to other computers in order to transfer files between the systems. Sometimes these applications are used to transfer copyrighted materials such as music and movies. Examples of P2P applications are BitTorrent, Gnutella, eMule, Ares Galaxy, Megaupload, Azureus, PPStream, Pando, Ares, Fileguri, Kugoo. Of these applications, BitTorrent has value in the scientific community. For purposes of this policy, The New England College of Optometry (College) refers to the College and its affiliate New England Eye Institute, Inc. Compliance: In order to comply with both the intent of the College’s Copyright Policy, the Digital Millennium Copyright Act (DMCA) and with the Higher Education Opportunity Act’s (HEOA) file sharing requirements, all P2P file sharing applications are to be blocked at the firewall to prevent illegal downloading as well as to preserve the network bandwidth so that the College internet access is neither compromised nor diminished. Starting in September 2010, the College IT Department will block all well-known P2P ports on the firewall at the application level. If your work requires the use of BitTorrent or another program, an exception may be made as outlined below. The College will audit network usage/activity reports to determine if there is unauthorized P2P activity; the IT Department does random spot checks for new P2P programs every 72 hours and immediately blocks new and emerging P2P networks at the firewall.
    [Show full text]
  • ARK​ ​​Whitepaper
    ARK Whitepaper ​ ​​ A Platform for Consumer Adoption ​ ​ ​ ​ ​ ​ ​ ​ v.1.0.3 The ARK Crew ARK Whitepaper v.1.0.3 ​ ​ ​ ​ ​ ​ ​ ​ Table Of Contents ​ ​ ​ ​ Overview………………………………………………………………...……………………………….……………….………………………………………………………….….3 ​ Purpose of this Whitepaper………………………………………………………………………………………………………………………..….……….3 ​ ​ ​ ​ ​ ​ ​ Why?…………………………………………………………………………………………………………………….…………………………………………………….…………..4 ​ ​ ARK…………………………………………………………………………………………………….……………….…………………………………………………………………..5 ​ ​ ARK IS………………………………………………………………………………………………....……………….………………………………………………………………..5 ​ ​ ​ ​ ARK: Technical Details……………………………………….…….…..…………………………...……………….………………...…………………………...6 ​ ​ ​ ​ ​ ​ - Delegated Proof of Stake…………………………….……………...………………………….……………………………………….………...…...6 ​ ​​ ​ ​ ​ ​ ​ ​ ​ - Hierarchical Deterministic (HD) Wallets ​ ​​ ​ ​ ​ ​ ​ ​ (BIP32)…………………………………………………….....…………………..…..8 ​ - Fees……………………………………………………………………………………………………………….……………….…...………………………………..……...8 ​ ​​ ​ - ARK Delegates and Delegate Voting.…………………………………………………………………………………...………………….9 ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ - Bridged Blockchains (SmartBridges)....................………………………………………………………………….………...…….10 ​ ​​ ​ ​ ​ ​ ​ - POST ARK-TEC Token Distribution …………………..…………………………………….………………….………..……..…..……….11 ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ - Testnet Release……………………………………………….…………………………………………………………………….………...….....12 ​ ​ ​ And Beyond?…………………………………………………………………….………...……………………………………….………………………...……….…12 ​ ​ ​ ​ Addendum 1: ARK IS…(Cont.)...……..……..…………....…..………...………………………………………...………………………......……12
    [Show full text]
  • IPFS and Friends: a Qualitative Comparison of Next Generation Peer-To-Peer Data Networks Erik Daniel and Florian Tschorsch
    1 IPFS and Friends: A Qualitative Comparison of Next Generation Peer-to-Peer Data Networks Erik Daniel and Florian Tschorsch Abstract—Decentralized, distributed storage offers a way to types of files [1]. Napster and Gnutella marked the beginning reduce the impact of data silos as often fostered by centralized and were followed by many other P2P networks focusing on cloud storage. While the intentions of this trend are not new, the specialized application areas or novel network structures. For topic gained traction due to technological advancements, most notably blockchain networks. As a consequence, we observe that example, Freenet [2] realizes anonymous storage and retrieval. a new generation of peer-to-peer data networks emerges. In this Chord [3], CAN [4], and Pastry [5] provide protocols to survey paper, we therefore provide a technical overview of the maintain a structured overlay network topology. In particular, next generation data networks. We use select data networks to BitTorrent [6] received a lot of attention from both users and introduce general concepts and to emphasize new developments. the research community. BitTorrent introduced an incentive Specifically, we provide a deeper outline of the Interplanetary File System and a general overview of Swarm, the Hypercore Pro- mechanism to achieve Pareto efficiency, trying to improve tocol, SAFE, Storj, and Arweave. We identify common building network utilization achieving a higher level of robustness. We blocks and provide a qualitative comparison. From the overview, consider networks such as Napster, Gnutella, Freenet, BitTor- we derive future challenges and research goals concerning data rent, and many more as first generation P2P data networks, networks.
    [Show full text]
  • A Decentralized Cloud Storage Network Framework
    Storj: A Decentralized Cloud Storage Network Framework Storj Labs, Inc. October 30, 2018 v3.0 https://github.com/storj/whitepaper 2 Copyright © 2018 Storj Labs, Inc. and Subsidiaries This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 license (CC BY-SA 3.0). All product names, logos, and brands used or cited in this document are property of their respective own- ers. All company, product, and service names used herein are for identification purposes only. Use of these names, logos, and brands does not imply endorsement. Contents 0.1 Abstract 6 0.2 Contributors 6 1 Introduction ...................................................7 2 Storj design constraints .......................................9 2.1 Security and privacy 9 2.2 Decentralization 9 2.3 Marketplace and economics 10 2.4 Amazon S3 compatibility 12 2.5 Durability, device failure, and churn 12 2.6 Latency 13 2.7 Bandwidth 14 2.8 Object size 15 2.9 Byzantine fault tolerance 15 2.10 Coordination avoidance 16 3 Framework ................................................... 18 3.1 Framework overview 18 3.2 Storage nodes 19 3.3 Peer-to-peer communication and discovery 19 3.4 Redundancy 19 3.5 Metadata 23 3.6 Encryption 24 3.7 Audits and reputation 25 3.8 Data repair 25 3.9 Payments 26 4 4 Concrete implementation .................................... 27 4.1 Definitions 27 4.2 Peer classes 30 4.3 Storage node 31 4.4 Node identity 32 4.5 Peer-to-peer communication 33 4.6 Node discovery 33 4.7 Redundancy 35 4.8 Structured file storage 36 4.9 Metadata 39 4.10 Satellite 41 4.11 Encryption 42 4.12 Authorization 43 4.13 Audits 44 4.14 Data repair 45 4.15 Storage node reputation 47 4.16 Payments 49 4.17 Bandwidth allocation 50 4.18 Satellite reputation 53 4.19 Garbage collection 53 4.20 Uplink 54 4.21 Quality control and branding 55 5 Walkthroughs ...............................................
    [Show full text]
  • P2P Protocols
    CHAPTER 1 P2P Protocols Introduction This chapter lists the P2P protocols currently supported by Cisco SCA BB. For each protocol, the following information is provided: • Clients of this protocol that are supported, including the specific version supported. • Default TCP ports for these P2P protocols. Traffic on these ports would be classified to the specific protocol as a default, in case this traffic was not classified based on any of the protocol signatures. • Comments; these mostly relate to the differences between various Cisco SCA BB releases in the level of support for the P2P protocol for specified clients. Table 1-1 P2P Protocols Protocol Name Validated Clients TCP Ports Comments Acestream Acestream PC v2.1 — Supported PC v2.1 as of Protocol Pack #39. Supported PC v3.0 as of Protocol Pack #44. Amazon Appstore Android v12.0000.803.0C_642000010 — Supported as of Protocol Pack #44. Angle Media — None Supported as of Protocol Pack #13. AntsP2P Beta 1.5.6 b 0.9.3 with PP#05 — — Aptoide Android v7.0.6 None Supported as of Protocol Pack #52. BaiBao BaiBao v1.3.1 None — Baidu Baidu PC [Web Browser], Android None Supported as of Protocol Pack #44. v6.1.0 Baidu Movie Baidu Movie 2000 None Supported as of Protocol Pack #08. BBBroadcast BBBroadcast 1.2 None Supported as of Protocol Pack #12. Cisco Service Control Application for Broadband Protocol Reference Guide 1-1 Chapter 1 P2P Protocols Introduction Table 1-1 P2P Protocols (continued) Protocol Name Validated Clients TCP Ports Comments BitTorrent BitTorrent v4.0.1 6881-6889, 6969 Supported Bittorrent Sync as of PP#38 Android v-1.1.37, iOS v-1.1.118 ans PC exeem v0.23 v-1.1.27.
    [Show full text]
  • How to Invest in Filecoin
    How to Invest in Filecoin Part I: Preparing to Invest Filecoin investments will be made on CoinList (coinlist.co), a US-based funding platform that connects investors to promising early-stage token sales. Created by Protocol Labs in partnership with AngelList, CoinList simplifies the token sale process and implements robust legal frameworks for token sales in the U.S. Before the sale begins, you will need to complete several preparation steps. Note that some steps include wait time of several days. For this reason, we recommend getting started as soon as possible and working in parallel while waiting for other steps to be reviewed or confirmed. Step 1: Create a CoinList account (5 min) Visit https://coinlist.co. Sign in with your AngelList account, or create a new account if needed. Step 2: Become a US accredited investor through AngelList (30 min + 1-3 day review) All token investors will need to meet US accredited investor requirements. Non-US investors can invest, but must meet the same requirements. You will be prompted to submit accreditation evidence. Step 3: Submit information for KYC/AML checks (15 min + instant review if no issues) You will be prompted to submit the details required for KYC/AML (Know Your Customer/Anti-Money Laundering) checks as soon as accreditation evidence has been submitted. You do not need to wait until accreditation review is complete. Step 4: Transfer funds to relevant accounts (10min + 1-5 day wait) You can invest with your choice of the following currencies: US Dollars, Bitcoin, Ether, and Zcash. To invest using US Dollars: Go to https://coinlist.co/settings/wallet.
    [Show full text]
  • Filecoin Token Sale Economics
    Filecoin Token Sale Economics This document describes various aspects of the Filecoin Network, the Filecoin Token Sale, and the economics of both. Any updates to this document will be posted on the CoinList webpage for the Filecoin Token Sale: https://coinlist.co/currencies/filecoin. LEGAL DISCLAIMER: This document contains forward-looking statements, ​ ​ ​ ​ ​ subject to risks and uncertainties that could cause actual results to differ materially. 1. Token Allocation The Filecoin Token will be distributed to the 4 major participating groups in the Filecoin Network. This allocation is written into the protocol itself and the Filecoin blockchain’s Genesis block. Each group is critical to the network’s creation, development, growth, and maintenance: ● 70% to Filecoin Miners (Mining block reward) ​ For providing data storage service, maintaining the blockchain, distributing data, running contracts, and more. ● 15% to Protocol Labs (Genesis allocation, 6-year linear vesting) ​ For research, engineering, deployment, business development, marketing, distribution, and more. ● 10% to Investors (Genesis allocation, 6 month to 3 year linear vesting) ​ ​ For funding network development, business development, partnerships, support, and more. ● 5% to Filecoin Foundation (Genesis allocation, 6-year linear vesting) ​ ​ For long-term network governance, partner support, academic grants, public works, community building, et cetera. 2. The Filecoin Token Sale Fundraising. Protocol Labs requires significant funding to develop, launch, and grow the Filecoin network. We ​ ​ ​ must develop all the software required: the mining software, the client software, user interfaces and apps, network infrastructure and monitoring, software that third-party wallets and exchanges need to support Filecoin, integrations with other data storage software, tooling for web applications and dapps to use Filecoin, and much more.
    [Show full text]
  • An Architecture for Client Virtualization: a Case Study
    Computer Networks 100 (2016) 75–89 Contents lists available at ScienceDirect Computer Networks journal homepage: www.elsevier.com/locate/comnet An architecture for client virtualization: A case study ∗ Syed Arefinul Haque a, Salekul Islam a, , Md. Jahidul Islam a, Jean-Charles Grégoire b a United International University, Dhaka, Bangladesh b INRS-EMT, Montréal, Canada a r t i c l e i n f o a b s t r a c t Article history: As edge clouds become more widespread, it is important to study their impact on tradi- Received 30 November 2015 tional application architectures, most importantly the separation of the data and control Revised 17 February 2016 planes of traditional clients. We explore such impact using the virtualization of a Peer- Accepted 18 February 2016 to-Peer (P2P) client as a case study. In this model, an end user accesses and controls the Available online 26 February 2016 virtual P2P client application using a web browser and all P2P application-related control Keywords: messages originate and terminate from the virtual P2P client deployed inside the remote Edge cloud server. The web browser running on the user device only manages download and upload of P2P the P2P data packets. BitTorrent, as it is the most widely deployed P2P platform, is used to BitTorrent validate the feasibility and study the performance of our approach. We introduce a proto- Virtual client type that has been deployed in public cloud infrastructures. We present simulation results Cloud-based server which show clear improvements in the use of user resources. Based on this experience we Web-RTC derive lessons on the challenges and benefits from such edge cloud-based deployments.
    [Show full text]
  • Migration in the Stencil Pluralist Cloud Architecture
    Migration in the Stencil Pluralist Cloud Architecture Tai Liu Zain Tariq Tencent America LLC New York University Abu Dhabi [email protected] [email protected] Barath Raghavan Jay Chen University of Southern California International Computer Science Institute [email protected] [email protected] ABSTRACT There are many important technical design challenges in decen- A debate in the research community has buzzed in the background tralized infrastructure, including security, naming, and more. Our for years: should large-scale Internet services be centralized or de- goal is to narrow the focus to the key issues the architecture must centralized? Now-common centralized cloud and web services have adjudicate as opposed to an individual application or service. We downsides—user lock-in and loss of privacy and data control—that argue that we need a pluralist architecture: one that allows the are increasingly apparent. However, their decentralized counter- co-existence of applications and seamless migration between them. parts have struggled to gain adoption, suffer from their own prob- Not only can such an architecture prevent user lock in, but it can lems of scalability and trust, and eventually may result in the exact also ease the pain of developing decentralized applications. Put same lock-in they intended to prevent. another way, a pluralist architecture is one that picks no winners: In this paper, we explore the design of a pluralist cloud architec- instead, it allows a marketplace of services to be developed, and ture, Stencil, one that can serve as a narrow waist for user-facing provides enough scaffolding and restrictions to ensure that the services such as social media.
    [Show full text]
  • Convergence-2020.Pdf
    A universal architecture to anonymize any application or protocol and turn it into an independent decentralized p2p network inside browsers and servers, with browsers acting as servers CONVERGENCE 1. Description This proposal is a complete redesign of our initial Convergence proposal from 2015 (http://www.peersm.com/Convergence.pdf ) which was intended as a research study for an EU call By “Convergence” in this proposal we don’t refer to a specific network or node but to methods using the Convergence principles 1.1 Background and rationale The initial Convergence proposal was written based on the observation that we must invent one network/system per need if we want to evade big data centralization and protect privacy/anonymity: to browse, to chat, to email, to exchange files, to do social networking or cooperative work, to do crypto currency, to protect the users from their connected objects, to handle peer identities. So it did envision the support of any type of applications and protocols on top of a secure anonymization system, inside browsers and servers The first part is very exactly what IPFS did, including the crypto currency concept in our proposal to sustain the network (Filecoin) But IPFS is not at all designed for privacy, the IPFS team knows that they will have to address the issue but it’s not even part of their roadmap And IPFS adoption is not for all protocols, many other networks will not use it and lack privacy too That’s why we are proposing the Convergence concepts, which are still very up to date, with a major novelty:
    [Show full text]