[Chat] Notes from the LCA2017 Libre Communications BoF
martin f krafft
madduck at madduck.net
Mon Jan 23 22:28:38 AEDT 2017
[Matthew, CC'ing you here, you can search down for "Matthew" or just
read it all…]
Hey,
around 20 of us met just before Friday lunch to discuss libre
real-time communication. It was a vivid discussion, but I tried to
take some notes, and here they come.
side-note: most of us will be available on the
#lca-matrix:matrix.org channel for real-time chat on any of these
topics, I'd say. It's bridged to #lca-matrix/chat.freenode.net.
WhatsApp and also Signal have seen wide-spread adoption, in part
because tying user accounts to phone numbers lowered the barrier of
entry and made it trivial for people to interconnect. An existing
network effect was leveraged.
Compare this to XMPP. As recently demonstrated,¹ it is possible to
configure Jabber-clients to enable all of the bells and whistles of
rich communications, but it takes a lot of effort. Furthermore, the
slow, bitwise addition of features/functionality to XMPP via XEPs
also means that few clients support the entire feature set (and only
on Linux). And if this wasn't enough of a hindrance to wide-spread
adoption, neither can XMPP reuse existing network effects, nor
exists there a directory making it easy to discover other users of
XMPP.
So early in the session, we pondered ways in which adoption can be
helped, especially in the context of the behemoths purposely
shielding their users from standards (cf. Google Hangouts no longer
supporting inbound XMPP, or Facebook/Cisco/others internally using
XMPP but not federating).
[intermission]
Could Facebook & Co. be interested in peering with a federated
service if they could push ads down that way? This would mean that
clients would need to support them.
What about a QR code at the next LCA, which gives people access to
a pre-configured XMPP app, possibly with optional, full-featured
default accounts for all attendees?
What could be done at the protocol level? We'll return to that
momentarily.
Lots of different protocols/technologies are in use among people in
the room, both for work and privately. It was a bit startling to see
the largest numbers next to Slack and Skype. But that's why we
convened…
Attendees pointed out a fundamental grouping of these protocols.
Some were social, i.e. mostly one-on-one, while others were more
team-oriented. For instance, Slack is about teams, Whatsapp strongly
pushes that way, but XMPP is mostly used for direct chats. It's
interesting to acknowledge in this context that IRC is channel-based
(see also this talk on the history of IRC²).
Many people seem to be using one tool for work and the other
privately, also as a means to separate the two, i.e. not to get
private content at work. It would thus be great if clients could
support profiles that enabled this.
Also, technology that natively bridges between protocols will make
it easier to adopt. Bitlbee is an external solution to integrate
instant messaging (ICQ, XMPP, Oscar, …) and even Twitter with IRC,
but Matrix contrariwise does this natively.
(At this point I (as well as Ben Sturm and Scott Bragg, who were
also in the room) answered a couple of questions about Matrix and
didn't take notes…)
Even though the session was not intended nor turned out to be
Matrix evangelism, I did talk a little bit about the concept of
identity servers that Matrix operates with. A Matrix user ID (MXID)
is of the form @madduck:matrix.org, and this weird-at-first format
was chosen on purpose to not conflate it with e-mail addresses.³ The
purpose of an identity server is e.g. to translate from an e-mail
address to the MXID. But it doesn't have to stop there.
[Matthew: here comes the bit presumably most interesting to you]
Michael Cassaniti stuck around from the keysigning BoF that took
place just before and mentioned keybase.io in this context. For
those who don't know, keybase.io is a project to build aggregate
identities through verification, i.e. my identity there might be
"the person who controls @martinkrafft on Twitter and also owns
madduck at debian.org, etc.". Maybe keybase.io could be turned into an
identity server and I could ask it "hey, I want to talk to
@martinkrafft on Matrix, please connect me…"
Finally, we discussed how to discover people you didn't know yet.
It's possible to build social graphs in decentralised fashion, and
people could be put in charge of the information they want to be
made available about them (e.g. like how on IRC your channel
membership is only revealed to others in the channel, or through
other means.
pump.io and also GNUsocial had furthermore seen "recommendation
servers", i.e. bots that would drink from various firehoses and
simply aggregate everything they found/heard of into a directory of
people/rooms/tags etc.. Such a directory could then be used
client-side to suggest new contacts, or discussion rooms or tags of
interest. It was agreed that finding out about rooms/tags had less
privacy implications, but there'd be no need to limit ourselves to
just that.
The session ended after an hour, and we didn't talk much about
microblogging, but all-in-all it felt like some interesting points
were raised and some food for thought given (cooked?), and I hope
I managed to capture it all in the above.
¹) e.g. http://www.trueelena.org/computers/howto/modern_xmpp_server.html
²) https://s3.eu-central-1.amazonaws.com/hsbp/camppp7e0/irc.mkv
³) https://matrix.org/docs/guides/faq.html#what-is-a-mxid
--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
"good advice is something a man gives
when he is too old to set a bad example.
-- la rouchefoucauld
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.lca2017.linux.org.au/pipermail/chat/attachments/20170124/a32f8c27/attachment-0001.sig>
More information about the Chat
mailing list