davidbgk
/
larlet-fr-david-cache

<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang=fr>
<!-- Has to be within the first 1024 bytes, hence before the <title>
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset=utf-8>
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
<!-- Required to make a valid HTML5 document. -->
<title>Paradigm shifts for the decentralized Web (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/static/david/icons/favicon.ico">
<meta name="apple-mobile-web-app-title" content="David Larlet">
<meta name="application-name" content="David Larlet">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- That good ol' feed, subscribe :p. -->
<link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/">

<style>
/* http://meyerweb.com/eric/tools/css/reset/ */
html, body, div, span,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, address, big, cite, code,
del, dfn, em, img, ins,
small, strike, strong, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section { display: block; }
body { line-height: 1; }
blockquote, q { quotes: none; }
blockquote:before, blockquote:after,
q:before, q:after {
  content: '';
  content: none;
}
table {
  border-collapse: collapse;
  border-spacing: 0;
}

/* http://practicaltypography.com/equity.html */
/* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */
/* https://www.filamentgroup.com/lab/js-web-fonts.html */
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');
  font-weight: 300;
  font-style: italic;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'ConcourseT3';
  src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),
       url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}


/* http://practice.typekit.com/lesson/caring-about-opentype-features/ */
body {
  /* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */
  font-family: "EquityTextB", Palatino, serif;
  background-color: #f0f0ea;
  color: #07486c;
  font-kerning: normal;
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: subpixel-antialiased;
  text-rendering: optimizeLegibility;
  font-variant-ligatures: common-ligatures contextual;
  font-feature-settings: "kern", "liga", "clig", "calt";
}
pre, code, kbd, samp, var, tt {
  font-family: 'TriplicateT4c', monospace;
}
em {
  font-style: italic;
  color: #323a45;
}
strong {
  font-weight: bold;
  color: black;
}
nav {
  background-color: #323a45;
  color: #f0f0ea;
  display: flex;
  justify-content: space-around;
  padding: 1rem .5rem;
}
  nav:last-child {
    border-bottom: 1vh solid #2d7474;
  }
  nav a {
    color: #f0f0ea;
  }
  nav abbr {
    border-bottom: 1px dotted white;
  }

h1 {
  border-top: 1vh solid #2d7474;
  border-bottom: .2vh dotted #2d7474;
  background-color: #e3e1e1;
  color: #323a45;
  text-align: center;
  padding: 5rem 0 4rem 0;
  width: 100%;
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
}
  h1.single {
    padding-bottom: 10rem;
  }
  h1 span {
    position: absolute;
    top: 1vh;
    left: 20%;
    line-height: 0;
  }
    h1 span a {
      line-height: 1.7;
      padding: 1rem 1.2rem .6rem 1.2rem;
      border-radius: 0 0 6% 6%;
      background: #2d7474;
      font-size: 1.3rem;
      color: white;
      text-decoration: none;
    }
h2 {
  margin: 4rem 0 1rem;
  border-top: .2vh solid #2d7474;
  padding-top: 1vh;
}
h3 {
  text-align: center;
  margin: 3rem 0 .75em;
}
hr {
  height: .4rem;
  width: .4rem;
  border-radius: .4rem;
  background: #07486c;
  margin: 2.5rem auto;
}
time {
  display: bloc;
  margin-left: 0 !important;
}
ul, ol {
  margin: 2rem;
}
ul {
  list-style-type: square;
}
a {
  text-decoration-skip-ink: auto;
  text-decoration-thickness: 0.05em;
  text-underline-offset: 0.09em;
}
article {
  max-width: 50rem;
  display: flex;
  flex-direction: column;
  margin: 2rem auto;
}
  article.single {
    border-top: .2vh dotted #2d7474;
    margin: -6rem auto 1rem auto;
    background: #f0f0ea;
    padding: 2rem;
  }
  article p:last-child {
    margin-bottom: 1rem;
  }
p {
  padding: 0 .5rem;
  margin-left: 3rem;
}
  p + p,
  figure + p {
    margin-top: 2rem;
  }

blockquote {
  background-color: #e3e1e1;
  border-left: .5vw solid #2d7474;
  display: flex;
  flex-direction: column;
  align-items: center;
  padding: 1rem;
  margin: 1.5rem;
}
  blockquote cite {
    font-style: italic;
  }
  blockquote p {
    margin-left: 0;
  }

figure {
  border-top: .2vh solid #2d7474;
  background-color: #e3e1e1;
  text-align: center;
  padding: 1.5rem 0;
  margin: 1rem 0 0;
  font-size: 1.5rem;
  width: 100%;
}
  figure img {
    max-width: 250px;
    max-height: 250px;
    border: .5vw solid #323a45;
    padding: 1px;
  }
figcaption {
  padding: 1rem;
  line-height: 1.4;
}
aside {
  display: flex;
  flex-direction: column;
  background-color: #e3e1e1;
  padding: 1rem 0;
  border-bottom: .2vh solid #07486c;
}
  aside p {
    max-width: 50rem;
    margin: 0 auto;
  }

/* https://fvsch.com/code/css-locks/ */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
  font-size: 1rem;
  line-height: calc( 1.5em + 0.2 * 1rem );
}
h1 {
  font-size: 1.9rem;
  line-height: calc( 1.2em + 0.2 * 1rem );
}
h2 {
  font-size: 1.6rem;
  line-height: calc( 1.3em + 0.2 * 1rem );
}
h3 {
  font-size: 1.35rem;
  line-height: calc( 1.4em + 0.2 * 1rem );
}
@media (min-width: 20em) {
  /* The (100vw - 20rem) / (50 - 20) part
     resolves to 0-1rem, depending on the
     viewport width (between 20em and 50em). */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );
    margin-left: 0;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
}
@media (min-width: 50em) {
  /* The right part of the addition *must* be a
     rem value. In this example we *could* change
     the whole declaration to font-size:2.5rem,
     but if our baseline value was not expressed
     in rem we would have to use calc. */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * 1rem );
    line-height: 1.5em;
  }
  p, li, pre, details {
    margin-left: 3rem;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * 1rem );
    line-height: 1.2em;
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * 1rem );
    line-height: 1.3em;
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * 1rem );
    line-height: 1.4em;
  }
  figure img {
    max-width: 500px;
    max-height: 500px;
  }
}

figure.unsquared {
  margin-bottom: 1.5rem;
}
  figure.unsquared img {
    height: inherit;
  }


@media print {
  body { font-size: 100%; }
  a:after { content: " (" attr(href) ")"; }
  a, a:link, a:visited, a:after {
    text-decoration: underline;
    text-shadow: none !important;
    background-image: none !important;
    background: white;
    color: black;
  }
  abbr[title] { border-bottom: 0; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  img { page-break-inside: avoid; }
  @page { margin: 2cm .5cm; }
  h1, h2, h3 { page-break-after: avoid; }
  p3 { orphans: 3; widows: 3; }
  img {
    max-width: 250px !important;
    max-height: 250px !important;
  }
  nav, aside { display: none; }
}

ul.with_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_columns {
    column-count: 2;
  }
}
@media (min-width: 50em) {
  ul.with_columns {
    column-count: 3;
  }
}
ul.with_two_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_two_columns {
    column-count: 1;
  }
}
@media (min-width: 50em) {
  ul.with_two_columns {
    column-count: 2;
  }
}

.gallery {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-around;
}
  .gallery figure img {
    margin-left: 1rem;
    margin-right: 1rem;
  }
  .gallery figure figcaption {
    font-family: 'ConcourseT3'
  }

footer {
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
  border-top: 3px solid white;
  padding: 4rem 0;
  background-color: #07486c;
  color: white;
}
  footer > * {
    max-width: 50rem;
    margin: 0 auto;
  }
  footer a {
    color: #f1c40f;
  }
  footer .avatar {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    float: left;
    -webkit-shape-outside: circle();
    shape-outside: circle();
    margin-right: 2rem;
    padding: 2px 5px 5px 2px;
    background: white;
    border-left: 1px solid #f1c40f;
    border-top: 1px solid #f1c40f;
    border-right: 5px solid #f1c40f;
    border-bottom: 5px solid #f1c40f;
  }
</style>

<h1>
  <span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>
  Paradigm shifts for the decentralized Web (archive)
  <time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>
</h1>
<section>
  <article>
    <h3><a href="https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/">Source originale du contenu</a></h3>
    <p>Most Web applications today follow the adage “your data for my services”. They motivate this deal from both <span class="nobr">a technical</span> perspective <em>(how could we provide services without your data?)</em> and <span class="nobr">a business</span> perspective <em>(how could we earn money without your data?)</em>. Decentralizing the Web means that people gain the ability <span class="nobr">to store</span> their data wherever they want, while still getting the services they need. <span class="nobr">This requires</span> major changes in the way we develop applications, as we migrate from <span class="nobr">a closed</span> back-end database to the open Web as our data source. In this post, <span class="nobr">I discuss</span> three paradigm shifts <span class="nobr">a decentralized</span> Web brings, demonstrating that decentralization is about much more than just controlling our own data. <span class="nobr">It is</span> <span class="nobr">a fundamental</span> rethinking of the relation between data and applications, <span class="nobr">which—if done</span> right—will accelerate creativity and innovation for the years <span class="nobr">to come</span>.</p> <p id="date"><time property="schema:datePublished" datetime="2017-12-20T12:00:00+01:00">20 December 2017</time></p> <p id="top-p-1"><a class="id" href="#top-p-1"/>The movement to <a href="https://www.wired.com/2017/04/tim-berners-lee-inventor-web-plots-radical-overhaul-creation/" target="_blank">(re-)decentralize the Web</a> is sometimes dismissively regarded as <span class="nobr">a modern-day</span> hippie reaction to the ever increasing power of technology giants such as Facebook and Google. And while the <em>David versus Goliath</em> way of thinking is definitely present among decentralists, there are many more advantages to <span class="nobr">a world</span> in which people and organisations regain the ability to store their data wherever they want—without missing out on the enormous potential and diversity the Web has <span class="nobr">to offer</span>.</p> <p id="top-p-2"><a class="id" href="#top-p-2"/>Ultimately, <strong>decentralization is about choice</strong>: we will choose where we <em>store</em> our data, who we give <em>access</em> to which parts of that data, which <em>services</em> we want on top <span class="nobr">of it,</span> <span class="nobr">and how</span> we <em>pay</em> for those. Nowadays, we are instead forced to accept <em>package deals</em> <span class="nobr">we cannot</span> customize. For example, Facebook shows us <span class="nobr">their social</span> feed featuring our friends, <span class="nobr">paid for</span> by advertising—but only if we store our personal data on Facebook. <span class="nobr">We cannot</span> see Twitter posts from others (unless they opt to copy their data to Facebook <span class="nobr">as well).</span> These deals are common, as virtually all Web applications we interact with behave in such <span class="nobr">a way.</span> Instead of arguing the <a href="/blog/2016/12/23/truth-takes-time/">appropriateness or ethics of this situation</a>, I’ll sketch the <strong>far-reaching effects of <span class="nobr">a decentralized</span> approach to Web development</strong>.</p> <figure id="top-figure-1"><a class="id" href="#top-figure-1"/> <img src="/images/blog/market.jpg" alt="[the Jemaa el-Fnaa market place at night]"/> <figcaption> Decentralization is not solely about data ownership: it fosters innovation and competition through separate markets for data and applications, requiring <span class="nobr">a new</span> development mindset. <span class="copyright">©<a href="https://www.flickr.com/photos/mierhhhlich/30550838731/" target="_blank">Damian Hedinger</a></span> </figcaption> </figure> <p id="top-p-3"><a class="id" href="#top-p-3"/>In this blog post, <span class="nobr">I will</span> discuss <strong>three paradigm shifts</strong> we need to prepare for if we want to build Web applications with a <span class="nobr">decentralized mindset</span>:</p> <ol> <li> <p id="top-p-4"><a class="id" href="#top-p-4"/><a href="#users-become-owners"><strong>End users become data owners</strong></a>. This is the most well-known decentralization aspect: we store our data in places of our choice, which improves privacy <span class="nobr">and control</span>.</p> </li> <li> <p id="top-p-5"><a class="id" href="#top-p-5"/><a href="#apps-become-views"><strong>Apps become views</strong></a>. As apps become decoupled from data, they start acting as interchangeable views rather than the single gateway to <span class="nobr">that data</span>.</p> </li> <li> <p id="top-p-6"><a class="id" href="#top-p-6"/><a href="#interfaces-become-queries"><strong>Interfaces become queries</strong></a>. Data will be distributed across highly diverse interfaces, so sustainable apps need declarative contracts instead of custom <span class="nobr">data requests.</span></p> </li> </ol> <p id="top-p-7"><a class="id" href="#top-p-7"/>These paradigm shifts are explained in depth below. I’ll use social networking sites as examples to simplify the narrative, but the principles generalize to all <span class="nobr">Web applications.</span></p> <h2 id="users-become-owners"><a class="id" href="#users-become-owners"/><em>Paradigm shift 1:</em> End users become data owners</h2> <p id="users-become-owners-p-1"><a class="id" href="#users-become-owners-p-1"/>The basis of decentralization is that <strong>people choose where they store their data</strong>. <span class="nobr">Instead of</span> having to pick between <span class="nobr">a handful</span> of providers such Google or Facebook, <span class="nobr">in a decentralized</span> world, there will be many options to pick from—and we are free to create our own. This idea brings us back to the <a href="https://www.theguardian.com/technology/2017/nov/15/tim-berners-lee-world-wide-web-net-neutrality" target="_blank">original vision for the Web</a>, where anyone has their own website or blog and publishes their thoughts on there, rather than in <a href="https://medium.com/matter/the-web-we-have-to-save-2eb1fe15a426" target="_blank"><em><span class="nobr">a single</span> stream</em></a> owned by <span class="nobr">one company</span>.</p> <p id="users-become-owners-p-2"><a class="id" href="#users-become-owners-p-2"/>To <span class="nobr">a certain</span> extent, we already have that choice: since its inception, the Web’s decentralized architecture has allowed anyone to have their own space. However, <span class="nobr">we want</span> the <strong>convenience of the single stream</strong> without the central control that currently comes <span class="nobr">with that.</span> We want to continue enjoying <strong>the same types of services</strong> that nowadays are only available on centralized platforms. So the important question is: can applications on top of decentralized data <strong>behave the same way as centralized apps</strong>? For example, can we still generate <span class="nobr">a friend</span> list and news feed like Facebook does—even if our friends’ data is stored on <span class="nobr">different servers</span>?</p> <p id="users-become-owners-p-3"><a class="id" href="#users-become-owners-p-3"/>The answer to these questions varies with <strong>different degrees of decentralization</strong>:</p> <figure id="axis"><a class="id" href="#axis"/> <img src="/images/blog/decentralization-axis.svg" class="white" alt="[an axis showing different degrees of decentralization]"/> </figure> <p id="users-become-owners-p-4"><a class="id" href="#users-become-owners-p-4"/>On the one end of the spectrum, <em>centralized solutions</em> store all personal data they use themselves: Twitter and Facebook are single data hubs for respectively millions and billions of users. In contrast, the <em>decentralized microblogging network</em> <a href="https://joinmastodon.org/" target="_blank"><strong>Mastodon</strong></a> lets anyone set up their own Twitter clone, counting <a href="http://www.ethanzuckerman.com/blog/2017/08/18/mastodon-is-big-in-japan-the-reason-why-is-uncomfortable/" target="_blank">around <span class="nobr">1.5 million</span> users spread across <span class="nobr">2,400 servers</span></a>. <span class="nobr">A couple</span> of thousand people share <span class="nobr">a server,</span> and the application can read content from people on other servers as well. The <a href="https://solid.mit.edu/" target="_blank"><strong>Solid</strong></a> platform takes this further, introducing the concept of <strong><em>one</em> <span class="nobr">data pod</span> per person</strong>. Such a <em><span class="nobr">data pod</span></em> is <span class="nobr">a simple</span> data storage location on <span class="nobr">a server,</span> equipped with <strong>highly granular access control</strong>, so anyone can decide exactly which people and apps can access what parts of their data. Applications become <em>clients</em> of these servers, sourcing data from multiple <span class="nobr">data pods.</span> Solid eventually envisages <span class="nobr">a world</span> of <strong><em>multiple</em> <span class="nobr">data pods</span> per person</strong>: one at home for personal data, one at the office for sensitive work files, one at school to track study material, etc. In this post, <span class="nobr">I assume</span> such <span class="nobr">a high</span> degree of decentralization. <span class="nobr">Note that</span> the names in the above axis are <em>envisaged</em> uses: it is theoretically possible to use Mastodon or Solid in different ways, and other <span class="nobr">platforms exist</span>.</p> <p id="users-become-owners-p-5"><a class="id" href="#users-become-owners-p-5"/>In <span class="nobr">a fully</span> decentralized social network, <strong>every single part of an interaction</strong>—which <span class="nobr">would now</span> be stored in its entirety on Facebook—<strong>could reside in <em>different</em> <span class="nobr">data pods</span></strong>. Consider this social media post, where an author states his professional opinion on <span class="nobr">an online news</span> article. Literally each single piece of data can be in another <span class="nobr">data pod:</span></p> <figure id="decentralized-facebook"><a class="id" href="#decentralized-facebook"/> <img src="/images/blog/decentralized-facebook.svg" class="white" alt="[a social media post, with different parts stored in different data pods]"/> </figure> <p id="users-become-owners-p-6"><a class="id" href="#users-become-owners-p-6"/>In the fully decentralized way of thinking, <strong>everything <em>you</em> post is stored on your own website or server</strong>. An app collects all posts from people <span class="nobr">I am</span> following from different servers, and displays them in <span class="nobr">a feed</span> for me. When <span class="nobr">I like</span> your post, <strong>this “like” is stored on <em>my</em> server</strong>. This action triggers my server to send a <a href="https://www.w3.org/TR/ldn/" target="_blank">notification</a> to yours, so you can decide whether to display this like or not—for instance, by storing <span class="nobr">a copy</span> of it. Every comment or like on any item is stored at <span class="nobr">a location</span> chosen by the poster, together with its associated permissions to read, write, or <span class="nobr">delete it</span>.</p> <p id="users-become-owners-p-7"><a class="id" href="#users-become-owners-p-7"/>This paradigm of <strong>storing everything in <span class="nobr">a place</span> we control</strong> is fundamentally different from the centralized one, and has several beneficial consequences for users. It improves <strong>privacy</strong>, since you can say whatever you want about anything, without having to disclose this to Facebook or anyone else. This positively impacts freedom of speech and goes against <a href="https://www.wsj.com/articles/norway-accuses-facebook-of-censorship-over-deleted-photo-of-napalm-girl-1473428032" target="_blank">censorship</a> <em>(with all of the associated <a href="http://www.ethanzuckerman.com/blog/2017/08/18/mastodon-is-big-in-japan-the-reason-why-is-uncomfortable/" target="_blank">consequences and debates</a>)</em>. <span class="nobr">The flexible</span> access control can be used in any way imaginable: even individual likes or comments could only <span class="nobr">be visible</span> to certain people, groups, or applications—and you can change those permissions at any time. All this is what it means to truly be a <strong>data owner</strong>.</p> <p id="users-become-owners-p-8"><a class="id" href="#users-become-owners-p-8"/>Other than with centralized platforms, <strong>trust</strong> is not derived from <span class="nobr">a single</span> party. For instance, if <span class="nobr">I claim</span> my post has <span class="nobr">124 likes,</span> then we believe this because Facebook says so (and frankly, we have no objective reason to doubt that). In <span class="nobr">a decentralized</span> scenario, <span class="nobr">I could</span> prove that by linking to the individual likes that are stored on other servers, which form a <strong>provenance trail</strong>. And if those links break for any reason (for instance, if people retract their like), <span class="nobr">I can</span> still prove they once liked it, if my <span class="nobr">app made</span> <span class="nobr">a copy</span> of their digitally signed like on my post. This mechanism can replace networks that are largely based on authority, such as LinkedIn, where people build <span class="nobr">a reputation</span> from the people they are connected to. We can essentially replace LinkedIn by an address book, where somebody is <span class="nobr">a connection</span> if they also have you in <em>their</em> <span class="nobr">contact list</span>.</p> <p id="users-become-owners-p-9"><a class="id" href="#users-become-owners-p-9"/>The main challenge with full decentralization of data is <strong>scalability</strong>. In the Mastodon scenario, there are still relatively few servers for many users. In the Solid scenario, there might even be more <span class="nobr">data pods</span> than users. In the end, decentralization will go hand in hand with <strong>dynamic data replication</strong>, which will need to be balanced carefully with fine-grained access control possibilities in order to guarantee <span class="nobr">data privacy</span>.</p> <h2 id="apps-become-views"><a class="id" href="#apps-become-views"/><em>Paradigm shift 2:</em> Apps become views</h2> <p id="apps-become-views-p-1"><a class="id" href="#apps-become-views-p-1"/>By <strong>breaking the tight coupling between data and applications</strong>, decentralization questions and alters the very nature of an application. While the second paradigm shift comes as <span class="nobr">a direct</span> consequence of the <a href="#users-become-owners">first paradigm shift</a> we discussed above, it is equally crucial in its <span class="nobr">own way</span>.</p> <p id="apps-become-views-p-2"><a class="id" href="#apps-become-views-p-2"/>Basically, the competitive advantage of many of today’s popular centralized platforms is their <a href="https://www.theguardian.com/technology/2010/nov/22/tim-berners-lee-facebook" target="_blank"><em><span class="nobr">data silo</span></em></a>, and the fact that <strong>their service depends entirely on access to that data</strong>. Conceptually speaking, the <em>service</em> offered by Facebook, Twitter, and LinkedIn is fairly simple and could be replicated easily by others. Yet <span class="nobr">a major</span> reason why people appreciate the services of these platforms is because of their data: Facebook is engaging because our friends’ data is there, Twitter has all of the world’s tweets and direct messages, and LinkedIn showcases our broad networks. In fact, these platforms have become <strong>inseparable from their data</strong>: we use “Facebook” to refer to both the application and the data that drives that application. The result is that nearly every Web app today tries to ask you for more and more data again and again, leading to dangling data on <a href="/articles/queryable-research-data/#introduction">duplicate and inconsistent profiles</a> we can no longer manage. <span class="nobr">And of course,</span> this comes with significant <span class="nobr">privacy concerns</span>.</p> <p id="apps-become-views-p-3"><a class="id" href="#apps-become-views-p-3"/>In contrast, decentralized Web applications decouple data and applications: <strong>you enter data <span class="nobr">only once</span></strong>—in your own <span class="nobr">data pod.</span> Instead of maintaining credentials with each app, you log in through your <span class="nobr">data pod</span> and <strong>give apps permission</strong> to read or write specific parts of your data. The Web’s ecosystem thereby evolves from bundled data+service packages into <strong><span class="nobr">applications as</span> interchangeable views</strong>, wherein each <span class="nobr">Web app</span> provides <em>consistent</em> visualizations, interactions, and processing over your personal <span class="nobr">data pod.</span> Furthermore, those apps let you interact with any other <span class="nobr">data pods</span> you have access to, such as those of your friends. <strong>Applications <em>ask</em> rather than <em>own</em></strong>, <span class="nobr">and they</span> are able to reuse data create by other apps, avoiding vendor lock-in.</p> <figure id="apps-as-views"><a class="id" href="#apps-as-views"/> <img src="/images/blog/apps-as-views.svg" class="white" alt="[decentralized Web applications share data from a personal data pod]"/> </figure> <p id="apps-become-views-p-4"><a class="id" href="#apps-become-views-p-4"/>In this ecosystem, Facebook’s friend feeds becomes a <strong>view over <em>your</em> contact list</strong> in <em>your</em> <span class="nobr">data pod,</span> combined with the latest messages your contacts have posted in <em>their</em> <span class="nobr">data pods.</span> Decentralized LinkedIn and Doodle could be <strong>granted access</strong> to your address book, so your list of colleagues would always be <span class="nobr">in sync</span> for meeting requests (because there would actually only be one list instead of multiple). Decentralized Doodle and Facebook could both be granted access to your calendar, where Doodle can only see when you are available, and Facebook can only add events. <strong>Any change in one view is directly reflected in another</strong> because they share the <span class="nobr">same storage</span>.</p> <p id="apps-become-views-p-5"><a class="id" href="#apps-become-views-p-5"/>Importantly, this disentanglement of data and services creates <strong>separate markets for data and applications</strong>. Each of those to markets comes with its own competitive forces that stimulate creativity and innovation at <span class="nobr">a higher</span> rate, since the ability to provide <span class="nobr">a service</span> no longer depends on ownership <span class="nobr">of data</span>.</p> <figure id="two-markets"><a class="id" href="#two-markets"/> <img src="/images/blog/data-and-app-markets.svg" class="white" alt="[competition on separate data and app markets facilitates innovation]"/> </figure> <p id="apps-become-views-p-6"><a class="id" href="#apps-become-views-p-6"/>On the <strong>application market</strong>, whoever can make <span class="nobr">a more</span> user-friendly social feed than Facebook, or show <span class="nobr">a better</span> network overview than LinkedIn, is able to attract people solely based on its quality of the service. Moreover, people can choose the application that serves them best, and can <strong>switch between applications at any time</strong>, since all apps are views over your personal <span class="nobr">data pod.</span> Instead of entering your name and e-mail address over and over again, you instead log in with your <span class="nobr">data pod</span> to give access to these pieces of data—and you can revoke this permission at any moment. Moreover, integration becomes simple: if an existing application lacks specific functionality, <span class="nobr">you can</span> easily write <span class="nobr">a small</span> app that provides <span class="nobr">a new</span> view on the <span class="nobr">same data</span>.</p> <p id="apps-become-views-p-7"><a class="id" href="#apps-become-views-p-7"/>On the <strong>data market</strong>, different options emerge as well. Depending on your requirements, you might prefer different storage providers. The most technologically advanced of us could decide to host their own server, possibly based on existing software packages. For <strong>personal purposes</strong>, people might select providers similar to Dropbox—the difference being that their choice only depends on storage aspects and not on application functionality. More expensive plans could for instance provide additional backup or security options. For <strong>professional purposes</strong>, an even wider range of solutions could exist, ranging from on-site storage to cloud-hosted packages. Universities could provide their students with storage for anything related to their education, and governments could do the same for citizens’ official documents. Specialized software solutions could emerge for law offices or hospitals, where sensitive data is treated appropriately according to data retention policies. Currently, such use cases require people to accept whatever application comes with their desired <span class="nobr">storage option</span>.</p> <p id="apps-become-views-p-8"><a class="id" href="#apps-become-views-p-8"/>The key to <span class="nobr">a healthy</span> ecosystem is the <strong>independence of these two markets</strong>, realized through <span class="nobr">a noncommittal</span> relationship between apps and data. Since there currently exists no such separation, new innovative application platforms have trouble emerging because they don’t have the data—and existing platforms lack incentives to innovate adequately because they already possess data data anyway. This competition argument is highly similar to the <strong>Net Neutrality</strong> debate, which strives to maintain the separation of the <a href="https://medium.com/@timberners_lee/act-now-to-save-the-internet-as-we-know-it-ccf47ce8b39f" target="_blank"><em>content</em> and <em>connectivity</em> markets</a>. Indeed, we can regard <span class="nobr">a fully</span> decentralized approach as <span class="nobr">a way</span> to realize <strong>platform neutrality</strong>, where applications and storage solutions become interchangeable, just like websites and <span class="nobr">Internet providers</span>.</p> <h2 id="interfaces-become-queries"><a class="id" href="#interfaces-become-queries"/><em>Paradigm shift 3:</em> Interfaces become queries</h2> <p id="interfaces-become-queries-p-1"><a class="id" href="#interfaces-become-queries-p-1"/>The third and final paradigm shift <span class="nobr">I will</span> discuss pertains to the <strong>communication between apps and <span class="nobr">data pods</span></strong>. It represents my own conclusion that I’ve drawn from the <a href="#users-become-owners">first</a> and <a href=":#apps-become-views">second</a> <span class="nobr">paradigm shifts</span>.</p> <p id="interfaces-become-queries-p-2"><a class="id" href="#interfaces-become-queries-p-2"/>The current generation of Web applications communicates with servers through a <strong>highly specific sequence of steps</strong> that are hard-coded into the application logic. These steps contain specific requests to <span class="nobr">a Web <abbr class="caps">API</abbr>,</span> <span class="nobr">a (typically</span> custom) interface exposed by the server. If applications become views over many different kinds of <span class="nobr">data pods,</span> <span class="nobr">an important</span> question is what interface these <span class="nobr">data pods</span> need <span class="nobr">to expose</span>.</p> <p id="interfaces-become-queries-p-3"><a class="id" href="#interfaces-become-queries-p-3"/>It seems unrealistic to hope that all of these <span class="nobr">data pods</span> would have the same <span class="nobr">Web <abbr class="caps">API</abbr></span> <span class="nobr">(be it</span> <a href="https://www.w3.org/TR/ldp/" target="_blank">Linked Data Platform</a>, <a href="https://www.w3.org/TR/sparql11-protocol/" target="_blank"><abbr class="caps">SPARQL</abbr></a>, or <a href="http://graphql.org/learn/serving-over-http/" target="_blank">GraphQL</a>). Not only would this require <span class="nobr">a standardization</span> effort without precedent, such <span class="nobr">a standard</span> could never cover all cases. Given that we aim for competition on the data market as well, different kinds of <span class="nobr">data pods</span> are <strong><em>expected</em> to provide different kinds of interfaces</strong> with varying expressivity. <span class="nobr">On top of this,</span> on <span class="nobr">a decentralized</span> Web, the data needed by applications will be <strong>scattered across <em>multiple</em> <span class="nobr">data pods</span></strong>. So even if all pods had the same interface, <span class="nobr">apps would</span> still need to route requests to the right pods and combine <span class="nobr">their data</span>.</p> <p id="interfaces-become-queries-p-4"><a class="id" href="#interfaces-become-queries-p-4"/>This indicates that <strong>decentralized apps shouldn’t bind directly to concrete <span class="nobr">Web <abbr class="caps">API</abbr>s</span></strong>, because this would limit them to specific <span class="nobr">data pods</span> at <span class="nobr">a specific</span> point in time. If their interfaces evolve, or if we want to access different <span class="nobr">data pods,</span> apps would need to be reprogrammed. Clearly, such <span class="nobr">a fragile</span> contract between the app and data markets would form <span class="nobr">a major</span> bottleneck to sustainable growth and scalability. Instead of hard-coding <span class="nobr">a specific</span> sequence of requests, the application logic should formulate in <span class="nobr">a higher-level</span> language what operation it wants to perform <span class="nobr">with data</span>.</p> <p id="interfaces-become-queries-p-5"><a class="id" href="#interfaces-become-queries-p-5"/>Therefore, <span class="nobr">I believe</span> that decentralized Web applications should exclusively use <strong><span class="nobr">declarative queries</span></strong> to view and update data on our pods, so their expression of the intended data operation remains constant—even if interfaces are different. Rather than directly interacting with pod interfaces, <strong>queries are processed by <span class="nobr">a client-side</span> library</strong>, which translates these queries into concrete <span class="nobr"><abbr class="caps">HTTP</abbr> requests</span> against one or multiple <span class="nobr">data pods.</span> This means that, rather than <span class="nobr">a horizontal</span> interface orientation or <span class="nobr">a vertical</span> interface that <em>directly</em> accesses the <span class="nobr">Web <abbr class="caps">API</abbr>,</span> decentralized Web applications need a <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.215.7100&amp;rep=rep1&amp;type=pdf#page=5" target="_blank"><strong>vertical interface orientation with an internal horizontal separation</strong></a>.</p> <figure id="query-based-interaction"><a class="id" href="#query-based-interaction"/> <img src="/images/blog/query-based-interaction.svg" class="white" alt="[the application-specific logic of a decentralized Web application interacts with a resuable query engine library]"/> </figure> <p id="interfaces-become-queries-p-6"><a class="id" href="#interfaces-become-queries-p-6"/>By abstracting all of an application’s operations as declarative queries, we enable an <strong>independent evolution</strong> of apps and server-side interfaces. At design time, apps only bind to slowly changing high-level queries instead of rapidly moving and changing low-level interfaces, so they don’t need to commit to <span class="nobr">a specific</span> <span class="nobr">data pod.</span> At runtime, the client-side query engine library—which can be shared across many applications—is responsible for interfacing with the concrete <span class="nobr">Web <abbr class="caps">API</abbr>s</span> of the relevant <span class="nobr">data pods</span> for <span class="nobr">a given</span> user. This also enables transparent data replication and aggregation, which will be necessary to speed up data collection across <span class="nobr">many pods</span>.</p> <p id="interfaces-become-queries-p-7"><a class="id" href="#interfaces-become-queries-p-7"/>While reducing the dependency of applications to queries facilitates their development and improves their sustainability, it implies a <strong>complex, cross-<abbr class="caps">API</abbr> query engine</strong>. <span class="nobr">I envision</span> that multiple implementations of such <span class="nobr">a query</span> library would compete, and eventually replace the <abbr class="caps">API</abbr>-specific client-side libraries that are symptomatic of tight coupling between clients, services, and their underlying data. <span class="nobr">A possible</span> direction to realize this in <span class="nobr">a scalable</span> way is to <strong><a href="https://arxiv.org/pdf/1609.07108v2.pdf" target="_blank">split monolithic <span class="nobr">Web <abbr class="caps">API</abbr>s</span> into <em><abbr class="caps">API</abbr> features</em></a></strong>, which can be reused across <span class="nobr">data pods.</span> These pods could then opt to provide different kinds of capabilities—such as <a href="https://www.w3.org/TR/ldp/" target="_blank">Linked Data Platform</a>, (subsets of) <a href="https://www.w3.org/TR/sparql11-protocol/" target="_blank"><abbr class="caps">SPARQL</abbr></a> and <a href="http://graphql.org/learn/serving-over-http/" target="_blank">GraphQL</a>, or <a href="https://www.hydra-cg.com/spec/latest/triple-pattern-fragments/" target="_blank">Triple Pattern Fragments</a>—depending on the service level chosen by their users. In the ideal case, <span class="nobr">a data pod</span> supports all queries required by the application, so the library can send them straight through; in other cases, it splits queries into <span class="nobr">multiple requests</span>.</p> <p id="interfaces-become-queries-p-8"><a class="id" href="#interfaces-become-queries-p-8"/>The combination of decentralization and query execution also confronts us with a <strong>temporally different way of interacting with data</strong>. In traditional <span class="nobr">Web applications,</span> the procedure is typically <em>“send query—wait for execution to complete—act on all results”</em>. <span class="nobr">In a decentralized</span> setting, we know that data collection <em>will</em> take time, so applications should be prepared to do more useful things instead of just waiting. The procedure becomes <em>“send query—act on each incoming result”</em>, processing every piece of incoming data a <strong>streaming</strong> way. In general, completeness should never be assumed, given that the Web is an open world. This is an additional indication of how radically the relation between data and applications <span class="nobr">will change</span>.</p> <h2 id="decentralization-as-the-way-forward"><a class="id" href="#decentralization-as-the-way-forward"/>Decentralization as the way forward</h2> <p id="decentralization-as-the-way-forward-p-1"><a class="id" href="#decentralization-as-the-way-forward-p-1"/>Each of the above paradigm shifts show that decentralizing the Web is about <strong>reorganizing power</strong>. First, people gain the power to control their own data and privacy. Second, new applications and data solutions gain competitive power through the resulting decoupling of apps and data. Third, the expressive power of applications improves by depending on transferable queries instead of low-<span class="nobr">level interfaces</span>.</p> <p id="decentralization-as-the-way-forward-p-2"><a class="id" href="#decentralization-as-the-way-forward-p-2"/>What <span class="nobr">I describe</span> in this blog post is <strong>slowly but steadily happening</strong>, and was in fact inspired by prototypes that currently exist. The decentralized editor <a href="https://dokie.li/" target="_blank"><strong>dokieli</strong></a> and its annotation functionalities convincingly demonstrate that every atomic piece of data can be stored in <span class="nobr">a different</span> place. Spending the summer at <abbr class="caps">MIT</abbr>’s <a href="http://dig.csail.mit.edu/" target="_blank">Decentralized Information Group</a> revealed the possibilities of simple server-side data stores such as <a href="https://solid.mit.edu/" target="_blank"><strong>Solid</strong></a> for advanced client-side applications. It’s there that <span class="nobr">I saw</span> for the first time how <em>data</em> can drive everything seamlessly—while apps become simple views. <a href="https://github.com/linkeddata/mashlib" target="_blank"><strong>Mashlib</strong></a> proves how everyday needs can be addressed with small applications, since these can tap into existing data instead of needing to duplicate input functionality to ask for basic details over and over. Finally, our work on <a href="http://linkeddatafragments.org/" target="_blank"><strong>Linked Data Fragments</strong></a>—and its <a href="https://github.com/solid/solid-tpf" target="_blank">Solid plugin</a>—aims to grow decentralized querying to <span class="nobr">a Web scale.</span></p> <p id="decentralization-as-the-way-forward-p-3"><a class="id" href="#decentralization-as-the-way-forward-p-3"/><span class="nobr">A question</span> many people have is whether <strong>decentralization is realistic</strong> in real-world scenarios. On the one hand, I’m inclined to answer that, in any case, the Web cannot possibly become more centralized than it already is today. Facebook has already become <span class="nobr">a main</span> gateway for such an immense number of people, that <strong>the only logical direction forward is less centralized</strong>. My conviction is based more than just gut feeling, since <span class="nobr">I see</span> several parties come to similar conclusions. On the other hand, <span class="nobr">I have</span> experienced the enormous potential of many aspects of the decentralized vision. The idea doesn’t need to start solely with enthusiastic technophiles, but can <strong>grow from concrete industry needs</strong>. The notion of <span class="nobr">a private,</span> on-premise <span class="nobr">data pod</span> appeals to sectors such as <em>finance</em>, <em>law</em>, and <em>healthcare</em>, which have <span class="nobr">a promising</span> market for high-security <span class="nobr">data pods</span> and transparent information access through apps <span class="nobr">as views.</span> From <span class="nobr">a digital</span> society perspective, personal <span class="nobr">data pods</span> address the problems we are facing with <strong>an increasing number of parties asking consistent access to specific parts of our personal data</strong>. <span class="nobr">I also</span> liked <a href="http://www.cs.rpi.edu/~hendler/" target="_blank"><span class="nobr">Jim Hendler</span></a> quoting <a href="https://web.media.mit.edu/~minsky/" target="_blank">Marvin Minsky</a> that we’ll know computers are truly becoming intelligent when they won’t ask for the same info twice <span class="nobr">ever again.</span> Approaching decentralization the right way will enable <span class="nobr">exactly that</span>.</p> <p id="decentralization-as-the-way-forward-p-4"><a class="id" href="#decentralization-as-the-way-forward-p-4"/>The final question is <strong>who will pay for all of this</strong>. The good news is that we’ll have <span class="nobr">a choice</span> there too. Bundled package deals such as Facebook and Twitter only offer the ad-based payment option with its <a href="https://webfoundation.org/2017/03/web-turns-28-letter/" target="_blank">infamous consequences</a>. In <span class="nobr">a decentralized</span> world, we can choose our data and app providers independently, and decide for each how we are willing to pay. The bad news is that this means <strong>not everything is going to be “free”</strong>, as <span class="nobr">it seemingly</span> appears now. However, increased competition—on two separate markets—should lead to fair prices. And if we really want free options, we could even imagine paying with our personal data, giving selected parts away in exchange for ads. That’s <span class="nobr">of course</span> how social media are implicitly supported now, but the main difference will be that <em>we</em> decide which data can be used for advertising purposes and which cannot. <span class="nobr">This proves</span> once more that, at its core, decentralization starts with us taking back control of our data, as <span class="nobr">a source</span> for <span class="nobr">a new</span> generation of innovative <span class="nobr">Web applications.</span></p></p>
  </article>
</section>


<nav id="jumpto">
  <p>
    <a href="/david/blog/">Accueil du blog</a> |
    <a href="https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/">Source originale</a> |
    <a href="/david/stream/2019/">Accueil du flux</a>
  </p>
</nav>

<footer>
  <div>
    <img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">
    <p>
      Bonjour/Hi!
      Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>
      Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).
    </p>
    <p>
      Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.
    </p>
    
    <p>
      Voici quelques articles choisis :
      <a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,
      <a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,
      <a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,
      <a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,
      <a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,
      <a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,
      <a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,
      <a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,
      <a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,
      <a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,
      <a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,
      <a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,
      <a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,
      <a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,
      <a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,
      et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>
    </p>
    <p>
      On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.
    </p>
    <p>
      Je ne traque pas ta navigation mais mon
      <abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>
      conserve des logs d’accès.
    </p>
  </div>
</footer>
<script type="text/javascript">
  ;(_ => {
    const jumper = document.getElementById('jumper')
    jumper.addEventListener('click', e => {
      e.preventDefault()
      const anchor = e.target.getAttribute('href')
      const targetEl = document.getElementById(anchor.substring(1))
      targetEl.scrollIntoView({behavior: 'smooth'})
    })
  })()
</script>