- From: Miles Fidelman <mfidelman@meetinghouse.net>
- Date: Tue, 16 Aug 2016 09:21:35 -0400
- To: public-rww@w3.org
- Message-ID: <16ab0f3c-61d2-713e-2858-f88499d81447@meetinghouse.net>
No, "business case" is not the key question - the question is what's the ecosystem to pay for costs. Or put another way, "economic model." Lots of folks use lots of software, because it's useful. The problem comes when infrastructure is needed to support that software. Then, somebody has to pay - but not necessarily as a business. Consider email. Yes, there are a few companies that make money out of email - both from selling software (e.g., Sendmail's commercial version) and from providing hosted services. But my and large, people's email clients are free (or come with their o/s), and their MTAs are hosted by an employer, or university, or alumni association, or ISP, etc., as a cost of doing business (and the software is mostly free). When it comes to Solid, and things like it: We've had decentralized applications for decades (Oceanstore & Publius come to mind, as well as Napster, Gnutella, etc.). And then there are decentralized file systems like Tahoe-LAFS, and replicated repositories like Git and LOCKSS. The problem really comes down to 'who pays for disk space.' Ultimately, if someone wants to "publish" something to the web, it has to live on disk, somewhere. Now, the files in question may be replicated, and/or dispersed - but ultimately, there are one or more copies sitting out on some number of disks, and someone is paying to maintain those drives and connect them to the net. And for people to actually use the service, en masse, it has to not only be easy, but there has to be an expectation of longevity and security. It really doesn't matter that much whether that comes from a for-profit business, a cooperative, or some hybrid - what matters is that there's a reliable mechanism. Right now, storage is essentially rented - stop paying and whatever you've just published goes away. What we really need is something akin to an endowment (or perpetual care for a cemetary plot) - pay once, and your "stuff" is in the cloud forever. One might envision a system where one puts money into a perpetual trust, with the income paying for storage. Better if the storage comes from multiple vendors, with replication. And better still if some of the income goes to defending against future takedown actions. That starts to look like persistent, reliable, secure long-term storage. Right now, as far as I can tell, there is one vendor (forever.com) that sort of offers this for collections of family photos - but they only guarantee 100 years, and it's a single vendor. A first step, but a long way from a perpetual, secure "publish to the cloud" service. Miles Fidelman On 8/16/16 8:51 AM, Adrian Hope-Bailie wrote: > What is the business case for a service provider to adopt Solid? > > Why would Google, Facebook or anyone that build's their business on > user data choose to let users take that away? > > Who will offer users a comparable service to these silos that attracts > them away but adopts Solid and can still make enough money to survive > competing with the biggest tech companies in the world? > > The point is not whether or not the architecture is easy the point is > whether it has the potential to make anybody any money because if it > doesn't then I think you will have a hard time persuading people to > use it, no matter how well it scales. > > On 15 August 2016 at 14:11, Melvin Carvalho <melvincarvalho@gmail.com > <mailto:melvincarvalho@gmail.com>> wrote: > > > > On 15 August 2016 at 14:08, Timothy Holborn > <timothy.holborn@gmail.com <mailto:timothy.holborn@gmail.com>> wrote: > > Solid isn't finished yet. > > > Solid is at version 0.6 rather than 1.0. > > But I dont really know what more can be added to it to get it to > v1.0. Im using it on a daily basis and it works fine. Some > people are perfectionists I suppose :) > > In any case its IMHO light years ahead of where the rest of the > web is, even if you only take small parts of it and use it. > > You can also argue that solid will never be finished, in the sense > that, the web will never be "finished". > > Its definitely something that can be used today. > > > On Mon, 15 Aug 2016, 10:07 PM Melvin Carvalho > <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> > wrote: > > On 15 August 2016 at 11:50, Adrian Hope-Bailie > <adrian@hopebailie.com <mailto:adrian@hopebailie.com>> wrote: > > From the article: "The question is whether > architecture will be enough." > > The answer is no. > We live in world where few ideas succeed without a > strong business case. The architecture is the easy part. > > > Architecture is deceptively difficult to get right. The > vast majority if systems start to fall over as they > scale. The web and REST are two architectures that buck > that trend and just get stronger as they scale. > > Solid is the next evolution in that architectural trend, > imho, because it simply embraces the points that made the > web great, and extends it a little bit, while being 100% > backwards compatible. Right now, it's the only system > that I know of, with this property, in fact, nothing else > is close. So this in itself, the ability to scale to > billions of users, is a business case. Quietly facebook > adopted the social graph approach to the web, and web > architectural principles with their graph protocol, and > also an implementation of WebID. > > I think what's true is that few ideas succeed, because > simply, we have a lot of ideas and a lot of competition. > Having a business can help, but the right architecture is > the magic sauce to get through those scalability barriers. > > I personally think Solid is the business opportunity of a > lifetime, perhaps even bigger than the first web. Im > certainly investing on that basis. > > > On 14 August 2016 at 10:49, Timothy Holborn > <timothy.holborn@gmail.com > <mailto:timothy.holborn@gmail.com>> wrote: > > Hi Anders, > > I'm using this email to respond to both [1] in > creds; in addition to the below, with some lateral > considerations. > > See this video where Mr Gates and Mr Musk are > discussing in China AI [2]. > > I haven't fully considered the implications, > whilst i've certainly been considering the issue; > i have not fully considered it, and as modern > systems become subject to government contracts as > may be the case with enterprise solutions such as > those vended by IBM [3], may significantly lower > the cost for government / enterprise, in seeking > to achieve very advanced outcomes - yet i'm unsure > the full awareness of how these systems work, what > potential exists for unintended outcomes when work > by web-scientists[4][5] becomes repurposed without > their explicit and full consideration of the > original designers for any extended use of their > works, what the underlying considerations are by > those who are concerned [6][7] and how these > systems may interact with more advanced HID as > i've kinda tried to describe recently to an > audience here [8] and has been further discussed > otherwise [9] [10]. > > I'm a little concerned about the under-resourcing > that seems to plague Manu's / Dave's original > vision (that included WebDHT) to the consultative > approach that i believed had alot of merit in how > it may interact with the works of RWW at the time > (alongside WebID) which have al progressed, yet, > not seemingly to a solution that i think is 'fit > for purpose' in attending to the issues before us. > > I have considered the need for people to own their > own biometric signatures. I have considered the > work by 'mico-project'[11] seems to be a good > supporter of these future works, particularly > given the manner in which these works support LDP > and other related technologies... > > But the future is still unknown, and what worries > me most; is those who know most about A.I. may not > be able to speak about it as a citizen or > stakeholder in the manner defined by way of a > magna carta, such as is the document that hangs on > my wall when making such considerations more > broadly in relation to my contributory work/s. > > i understand this herein; contains an array of > fragments; yet, am trying to format schema that > leads others to the spot in which i'm processing > broader ideas around what, where and how; progress > may be accelerated and indeed adopted by those > capable of pushing it forward. > > I remember the github.com/Linkeddata > <http://github.com/Linkeddata> team (in RWW years) > wrote a bunch of things in GO, which is what the > IPFS examples showcase, and without providing > exhaustive links, i know Vint has been working in > the field of inter-planetary systems [13], therein > also understanding previous issues relating to > JSON-LD support (as noted in [1] or [14] ), which > in-turn may also relate to other statements made > overtime about my view that some of the works > incubated by credentials; but not subject to IG or > potential WG support at present - may be better > off being developed within the WebID community as > an additional constituent of work that may work > interoperable with WebID-TLS related systems. > > Too many Ideas!!! > > (perhaps some have merit...) > > Tim.H. > > > [1] > https://lists.w3.org/Archives/Public/public-credentials/2016Aug/0045.html > <https://lists.w3.org/Archives/Public/public-credentials/2016Aug/0045.html> > > [2] https://youtu.be/TRpjhIhpuiU?t=16m26s > <https://youtu.be/TRpjhIhpuiU?t=16m26s> > [3] http://blog.softlayer.com/tag/watson > <http://blog.softlayer.com/tag/watson> > [4] http://webscience.org/ > [5] > https://twitter.com/WebCivics/status/492707794760392704 > <https://twitter.com/WebCivics/status/492707794760392704> > > [6] https://www.youtube.com/watch?v=tV8EOQNYC-8 > <https://www.youtube.com/watch?v=tV8EOQNYC-8> > [7] > https://en.wikipedia.org/wiki/Open_Letter_on_Artificial_Intelligence > <https://en.wikipedia.org/wiki/Open_Letter_on_Artificial_Intelligence> > > [8] (perhaps not the best reference, but has a > bunch of ideas in it: > https://docs.google.com/presentation/d/1RzczQPfygLuowu-WPvaYyKQB0PsSF2COKldj1mjktTs/edit?usp=sharing > <https://docs.google.com/presentation/d/1RzczQPfygLuowu-WPvaYyKQB0PsSF2COKldj1mjktTs/edit?usp=sharing> > > [9] https://www.youtube.com/watch?v=iTqF3w2yrZI > <https://www.youtube.com/watch?v=iTqF3w2yrZI> > [10] https://www.youtube.com/watch?v=_x_VpAjim6g > <https://www.youtube.com/watch?v=_x_VpAjim6g> > [11] http://www.mico-project.eu/technology/ > <http://www.mico-project.eu/technology/> > [12] https://www.youtube.com/watch?v=8CMxDNuuAiQ > <https://www.youtube.com/watch?v=8CMxDNuuAiQ> > [13] > http://www.wired.com/2013/05/vint-cerf-interplanetary-internet/ > <http://www.wired.com/2013/05/vint-cerf-interplanetary-internet/> > > [14] https://github.com/ipfs/ipfs/issues/36 > <https://github.com/ipfs/ipfs/issues/36> > On Fri, 12 Aug 2016 at 14:47 Anders Rundgren > <anders.rundgren.net@gmail.com > <mailto:anders.rundgren.net@gmail.com>> wrote: > > On 2016-08-11 15:16, Melvin Carvalho wrote: > > Really good article, mentions Solid and other > technologies. WebID is mentioned by the > author in the comments too ... > > > http://www.digitaltrends.com/web/ways-to-decentralize-the-web/ > <http://www.digitaltrends.com/web/ways-to-decentralize-the-web/> > One of the problems with the Web is that there > is no easy way letting a provider know where > you come from (=where your Web resources > are). This is one reason why OpenID rather > created more centralization. The same problem > is in payments where the credit-card number is > used to find your bank through complex > centralized registers. Both of these use-cases > can be addressed by having URLs + other > related data such as keys in something like a > digital wallet which you carry around. There > is a snag though: Since each use-case needs > special logic, keys, attributes etc. it seems > hard (probably impossible), coming up with a > generic Web-browser solution making such > schemes rely on extending the Web-browser > through native-mode platform-specific code. > Although W3C officials do not even acknowledge > the mere existence(!) of such work, the > progress on native extensions schemes has > actually been pretty good: > https://lists.w3.org/Archives/Public/public-webappsec/2016Aug/0005.html > <https://lists.w3.org/Archives/Public/public-webappsec/2016Aug/0005.html> > This is approach to decentralization is BTW > not (anymore) a research project, it is fully > testable in close to production-like settings > today: https://test.webpki.org/webpay-merchant > <https://test.webpki.org/webpay-merchant> The > native extensions also support a > _decentralized_development_model_for_Web_technology_, > something which is clearly missing in world > where a single browser vendor has 80% of the > mobile browser market! Anders > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
Received on Tuesday, 16 August 2016 13:22:04 UTC