Re: Reviewing the Solid protocol

My note about 'pod' is a more generic problem with external storage (especially semi-structured, or structured)  that is not directly under the control of the user - SOLID being one case. Minimally these systems expose the user to risk of denial of service, and creates pressure for centralization. Saying that users a free to host their own server is a poor answer because historically the people that have actually done that are on the fringe... how many people choose to host a webdav server instead of using google drive or dropbox?

Another good example of a similar nature is medical records - everyone decries the rough monopoly that EPIC holds, and there are a myriad proposals (many of which use blockchain as a meme to imply security and decentralization) that boil down to "EPIC is an evil centralized monopoly that is monetizing your data! We must be free of this - all you have to do is move your data into our system, and we can break the chains!". The outcome of that is obvious given the business incentives.

It's not clear that path forward is to have a server-based system for sovereign data at all. Given the storage capacity of modern mobile devices, broadly available connectivity, and modern cryptography, there are other approaches. Would exploring those fall under the charter?

On Sat, Apr 8, 2023, at 1:25 AM, Melvin Carvalho wrote:
> 
> 
> st 29. 3. 2023 v 3:21 odesílatel Gavin Nicol <gtn@rbii.com> napsal:
>> __
>> There are quite a few competitors to Solid out there in various forms: self-sovereign identity, self-sovereign data etc. are all being/have been worked on for quite some time now (at least 10 years) and it still feels premature to standardize on anything. There are lots of technical and social issues to work out...  in the case of Solid (nominally decentralized), it's somewhat questionable why a Pod is necessary, for example.
> 
> Hi Gavin, the term pod has been removed from the charter
> 
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fraw.githubusercontent.com%2Fsolid%2Fsolid-wg-charter%2Ffix%2Fcharter-drafts-template%2Fcharter%2Findex.html&doc2=https%3A%2F%2Fraw.githubusercontent.com%2Fsolid%2Fsolid-wg-charter%2Ffix%2Fuse-technical-terms-storage%2Fcharter%2Findex.html
> 
> And also occurs nowhere in the spec.
> 
> Instead the term "storage" is used, which can be thought of as an enhanced WebDAV with access control
> 
> If you had examples of competitors, it may be possible to do a comparison
>  
>> 
>> 
>> On Tue, Mar 14, 2023, at 11:30 PM, Danny Ayers wrote:
>>> It is in scope for TAG, the W3C and whatever. But the idea your version is the one. If you want to keep the W3C relatively independent, that doesn't work. If Microsoft and Apple have to drop their version of scripts, so should you.
>>> 
>>> On Sun, 24 Jul 2022 at 15:18, Tim Berners-Lee <timbl@w3.org> wrote:
>>>> Solid is a growing protocol/movement, and the tech parts of it — the Solid Project — are basically a W3C Community group.
>>>> 
>>>> Solid adds things which the web needed but hadn’t yet standardized, including global single sign-in, standard access control, and a fast API for data read-write between an app and a store (a Solid Pod).  By making the API to the store universal, it means you don’t have to change the store when you make a new app, which completely changes the architecture and markets and business models which are possible. It also leaves individuals empowered rather than exploited.
>>>> 
>>>> Would it be reasonable for the TAG to review the architecture at a high level, or review the protocol?  It would be useful to get a knowledge of the Solid stack in neighboring parts of the technology.
>>>> 
>>>> (A separate future question are the client-client interop specs which are needed for interop between apps, such as contacts, chat, etc.)
>>>> 
>>>> See https://solidproject.org/. https://solidproject.org/TR is where the specs end up after their github-based proces.
>>>> 
>>>> Best wishes
>>>> 
>>>> Tim BL
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> ----
>>> 
>>> https://hyperdata.it <http://hyperdata.it/danja>
>>> 
>> 

Received on Monday, 10 April 2023 17:53:04 UTC