[lca2018-chat] Notes from the "Decentralise all the things" BoF

[martin f. krafft]

OMG it's March and LCA feels like an eternity ago. Sorry for being
such a slacker.

During our excellent conference in Sydney, a few of us sat down over
the BBQ lunch on Friday to discuss the topic of decentralisation, as
was announced here: https://wiki.linux.conf.au/wiki/Decentralise_All_The_Things

Rather than a focused discussion on e.g. Matrix and identity
servers, which we had at the predecessor meeting in Geelong,¹ this
time it was more of a show-and-tell of interesting projects. Though,
of course, we also talked Matrix, as one does…

¹) http://lists.lca2017.linux.org.au/pipermail/chat/2017-January/000407.html

For posterity, and in case it could inspire anyone of you, here are
the notes I took. Sorry if these are quite scattered, but as I said,
we shared a lot of ideas without really having the time to go into
depth on any of them.

1. Trust in mesh networks — The OLPC project, as inactive as it may
   be, always had the goal to enable collaboration in meshes, i.e.
   kids in a class room linking up with each other. When you're
   sitting next to each other, then trust is kinda easy, but what is
   trust anyway? It's basically just a function of all the previous
   encounters, and ideally should be evaluated at every new
   encounter.

   So imagine a pane next to your chat window (or e-mail client, or
   web site, or collaborative environment, or or or…) that simply
   lists your previous encounters, possibly augmented with
   statements about the WoT to depth 1, i.e. "this is a friend of
   your mother". Some tools already do this, I'm sure, but not in an
   overarching way; well, at least we couldn't name any.

   I've always wanted a CRM that was easy to use and integrated with
   everything that I do, such that I could take notes on e.g. some
   news about my correspondent's kids, or some health issue, or some
   award, or anniversary, such that I could use those data during
   the next encounter, rather than expecting myself to memorise and
   remember it all (I don't…). Trust really isn't anything
   different, now is it?

2. Bridging between walled gardens — such as between Matrix and
   Wire, requires per-user bridges that handle credentials, because
   e2e encryption algorithms are mostly incompatible between all the
   big players. However, there's nothing that fundamentally speaks
   against installing e.g. a Wire bridge as a plugin into my Matrix
   client (rather than one bridge for all users of a server), except
   it better be seamless for the user.

   Take this one step further: why isn't the Matrix server built
   straight into clients, with some sort of decentralised storage
   and message queues so that mobile clients don't need to be on
   the equivalent of caffeine all the time.

3. On the note of decentralised storage, I mentioned that MAIDSAFE
   may be a project of interest, similar to IPFS. Nobody present had
   real experience with it at the point though.

4. Blockchain establishes global consensus, but when you can
   pre-define static conflict resolutions, then HistoryGraph is an
   interesting means to keep track of a shared state in distributed
   environments.

5. Several technologies, especially those around conferencing,
   currently rely on TURN-servers to synchronise data endpoints.
   This is a centralisation aspect that could be mitigated using
   e.g. anycast UTURN-servers, or establishing large pools of them,
   such as pool.ntp.org…

6. OpenTimestamp.org is a project anyone can use to publish
   assertations to the blockchain. Essentially, that means
   timestamping a hash sum, i.e. if I have a great idea written up,
   I might submit it to OTS and get a receipt that I can later use
   to prove to the world that I had this idea before the given
   timestamp. The project is very interesting because assertations
   seem to be at the core of a lot of the times when people want to
   use blockchain to solve whatever problem. OTS uses uses
   centralised calendar servers to aggregate such assertations, and
   later, an unlimited number of such assertations can (and will
   automatically) be submitted to the public Bitcoin blockchain.
   Seems like an interesting compromise, and similar to the
   Lightning network. Still, who pays for this?

7. Towards the end, we struck up the identity server of matrix.org
   again, but ran out of time. Not before a mention of OpenWhisper's
   zero-knowledge directory was dropped though. There was no time,
   so here's simply a link: https://signal.org/blog/private-contact-discovery/

Looking forward to any feedback or thoughts, of course.

-- 
@martinkrafft | http://madduck.net/
 
"every day is long. 86400 doesn't fit in a short."
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.lca2018.linux.org.au/pipermail/lca2018-chat/attachments/20180305/4df58c95/attachment.sig>