W3C home > Mailing lists > Public > www-tag@w3.org > January 2016

Re: Thoughtful piece on the costs of the siloing of social media

From: Philip Sheldrake <philip@eulerpartners.com>
Date: Fri, 8 Jan 2016 18:04:41 +0000
Message-ID: <CAD0eYd52X6ppSoL3LVe7V3Paciy_Edwad0-uOGwZ40Ayjq0PBQ@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>, Mark Nottingham <mnot@mnot.net>, Carvalho Melvin <melvincarvalho@gmail.com>, Henry Thomson <ht@inf.ed.ac.uk>, timbl@w3.org, TAG List <www-tag@w3.org>
Thanks for namechecking the hi:project Henry, and hi everyone.

A brief introduction… I’m doing a PhD in Web and Internet Science under the
supervision of Prof Wendy Hall and Dr. Kieron O'Hara, and I’m an architect
of the hi:project, endorsed by the Web Science Trust. (I was invited to
undertake the former on the basis of the latter.) I'm part of the SOCIAM
programme – Universities of Oxford, Southampton and Edinburgh.

I won’t describe the hi:project here (our homepage <http://hi-project.org/>
attempts that) but will riff briefly wrt distributed architecture; a
primary objective.

Jon ‘Maddog’ Hall noted that our project effectively reverses the current
client server power asymmetry, effectively democratising the server (server
in the browser; define browser) to the point where the distinction might
well dissolve. Especially of course when combined with the likes of a
linked data platform.

The HI (human interface as opposed to UI
<http://hi-project.org/faqs/what-do-you-mean-by-human-interface/>) is
wholly compatible with the EFF’s Game Plan for Ending Global Mass
Surveillance, specifically: "Create a global movement that encourages
user-side encryption."

We’re keeping close to SoLiD since the SOCIAM all-hands at Oxford in
September. As you can see from our latest blog post
<http://hi-project.org/2015/12/solid-introduction-mit-csails-andrei-sambra/>
(by Andrei Sambra, intro by me), we’re running with this way of describing
things right now … “Solid decouples the app from the data, and the
hi:project decouples the interface from the app.” And this post explains
why we might, just might, if we can get this thing off the ground, why we
might be a trojan horse for the adoption of SoLiD – decentralization cannot
be marketed
<http://hi-project.org/2015/10/decentralization-cannot-be-marketed/>.

The project encourages decentralization at the application layer, although
it doesn't contribute to ameliorating the weaknesses of DNS / HTTP you
describe in your post Mark (we are attracted however to distributing the
hi:components IPFS style for sure). But we do have another objective at
heart ...

We're cognisant that none of us aspire to redecentralize for
decentralization's sake. As I noted in this guest post to the Drucker Forum
<http://hi-project.org/2015/09/drucker-society-the-human-web-and-sustainability/>
ahead of the 7th Global Drucker Forum last year, "the ultimate information
technology challenge is the care and maintenance of a digital
infrastructure that can help us rise up to so-called super wicked problems,
collectively. Given the growing appreciation of the nature of complexity
and the complexity of nature, we know we’re in the domain of systems
thinking and sustainability – the health and resilience of living systems
including our planet, our societies, and our organisations.

Sustainability requires healthy, *distributed* networks, with both
diversity and individual *agency*, to facilitate the emergence of
collective intelligence. It is these qualities our digital technologies
must enable and encourage."

The hi:project aims then to contribute to redecentralization, but just as
importantly it's directed squarely at liberating individual agency too by
helping to solve personal data & privacy, helping secure a citizen-centric
Internet of Things, and transforming accessibility & digital inclusion.


Thanks for your time. And it goes without saying that I'd love to continue
the conversation should the project interest you.

Cheers, Philip.

*__*

Philip Sheldrake, CEng MIET
Architect, the hi:project
Managing Partner, Euler Partners
Main Board Director, techUK

M. +44 (0)7715 488 759
Blog www.philipsheldrake.com
Skype psheldrake
Twitter @sheldrake


On 8 January 2016 at 11:53, Henry Story <henry.story@bblfish.net> wrote:

>
> > On 8 Jan 2016, at 04:09, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > [ I remember seeing that article somewhere other than the Guardian quite
> a few months ago, but forget where; anyone? ]
> >
> > Personally, I'm very interested, but the Web as currently designed and
> implemented heavily encourages centralisation, and changing it is likely
> harder than just starting something new.
> >
> > Some related thoughts here:
> >  https://www.mnot.net/blog/2015/08/18/distributed_http
>
> Very interesting read. Thaks for the link to Brewster Kahl's talk at
> the Chaos Communications Congress which helps get into this:
>
> https://media.ccc.de/v/camp2015-6938-locking_the_web_open_call_for_a_distributed_web
>
> Here's a way of thinking of the centralisation problem in layers that I
> have
> found helpful recently (I'll get to Brewsters decentralised view right
> after).
> We have three layers:
>
>  1) IPv4/6 Information layer (+1): any machine can talk to any machine to
> retrieve data using IPv4/6. It's a pure p2p layer.
>  2) Web of Docuemts (+1): any document can link to any other document
>    Pure p2p layer
>  3) Web Applications (-1): most data driven apps are not cross domain
>
>
> It is at layer 3 that currently the problem is being felt, and for many
> people
> this may seem very weird: how can you have decentralisation at lower
> layers, and
> not higher ones? How come bytes can flow around the internet in a peer to
> peer
> manner but data does not? How come there are so many services that exist
> in any
> of a number of categories that don't interoperate?
>
> For example: OuiShare, the European Sharing Economy conference, with
> collaborators around Europe put together a list of tools that their
> "connectors" use:
>
>   https://trello.com/b/qPtU1EbQ/ouishare-collaboration-tools
>
> There are 13 categories of tools, hardly any of them really interoperate.
> Each
> time people want to work together they need to start from scratch and find
> a new
> tool that they all agree to work on together. This has a huge cost.
>
> So we don't just have centralisation: we also have fragmentation.
> Ie. we don't have linkability in the data world. Or rather we only have
> linkability at the data layer within a single service, except for a
> few cases such as RSS feeds.
>
>   We have hyper text but not hyper data.
>
> ( well actually we are working on HyperData based apps
>   - High lieve concept http://hi-project.org/
>   - Social Linked Data spec: https://github.com/solid/solid-spec
> )
>
> Now what Brewster Kahl wants is something more than this. They are thinking
> p2p for resources so that these can be spread around and duplicated across
> servers. I don't think of this as incompatible with the current web: it
> just
> requires a new resource discovery protocol ( something like bittorent )
> and new
> URLs for those resources, which could in any case map to http urls.
>
>         If you listen to Brewster's answers  to the questions in the CCC
> talk it
> seems he is still thinking very much of a world  of documents. But actually
> what he should really want, given his examples of large centralised
> providers,
> is a distributed replicated _data_ web.  Then the client could actually
> follow the
> data around  and build up an interface for the user's particular needs
> ( http://hi-project.org/ )
>
> Given that the semantic web itself is based  on URIs and so is protocol
> agnostic,
> there is no problem connecting data published on http, https, onion, or
> other protocols.
> Logically this has already been dealt with by the w3c.
>
> More intriguing is how one could have distributed versioned data where
> some data is
> access controlled. The data would have to be encrypted, but if one gave
> anyone the key,
> that person could give anyone else the key too - but perhaps that's not
> more of a problem
> than when someone copies and republishes a document that is access
> controlled.
>
> So in summary:
>   - the problem of centralisation/fragmentation is occuring at the data
> layer
>   - the answer to that is using linked data
>   - building replicated version data protocols
>      + will make linked data even more important
>      + is not incompatible with the current web architecture
>
> Henry Story
> http://co-operating.systems/
>
> >
> > Cheers,
> >
> >
> >> On 8 Jan 2016, at 11:55 am, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
> >>
> >>
> >>
> >> On 5 January 2016 at 20:51, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
> >>
> http://www.theguardian.com/technology/2015/dec/29/irans-blogfather-facebook-instagram-and-twitter-are-killing-the-web
> >>
> >> This is a really interesting piece, thanks for sharing.
> >>
> >> The web does seem to have become more centralized in the last few
> years.  I dont know how much of this is architectural, and how much
> behavioral.
> >>
> >> The architectural foundations of the web as a cross origin document
> (and data) space, are I think, quite strong, leading to a good degree of
> decentralization.  I dont know why the web may be becoming more
> centralized, I once heard someone say "no matter how decentralized you
> design a system, centralization creeps in through the back door".
> >>
> >> My personal preference would be to see a healthy centralized and
> healthy decentralized element of the web competing with each other and
> offering greater user choice.  But we dont seem to live in that world,
> right now, at least.
> >>
> >> One factor, imho, is that there are probably orders of magnitude more
> people working on centralized solutions, than on decentralized.  Also
> decentralized solutions are fragmented, due to design decisions that get in
> the way of interop (tho interop is hard at the best of times).
> >>
> >> Im not sure what the TAG can do about this, or even how many on the TAG
> list still are interested in a decentralized web (tho I know TIm is).  One
> thing that may be valuable is guidelines to developers building
> decentralized solutions on how to prevent fragmentation, and how to
> encourage interop.  It's a difficult problem to talk about, let alone to
> solve!
> >>
> >>
> >>
> >> ht
> >> --
> >>       Henry S. Thompson, School of Informatics, University of Edinburgh
> >>      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131
> 650-4440
> >>                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
> >>                       URL: http://www.ltg.ed.ac.uk/~ht/
> >> [mail from me _always_ has a .sig like this -- mail without it is
> forged spam]
> >>
> >>
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> >
>
>
Received on Monday, 11 January 2016 21:34:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:13 UTC