[Sugar-devel] [IAEP] Google Code In wrap up

[D. Joe]

On Tue, Jan 17, 2017 at 11:41:07PM +0100, Jonas Smedegaard wrote:
> > On Tue, Jan 17, 2017 at 4:52 PM, Dave Crossland <dave at lab6.com> wrote:
> >> Regarding a possible move from IRC to Slack, or Gitter, or something 
> >> else as suggested by Ignacio, I wonder that we could just upgrade 
> >> http://chat.sugarlabs.org from qwebchat to http://demo.shout-irc.com 
> >> :)

As a web client that looks ok. 

The main driver I've seen in the move to things other than IRC seems to be a
usable mobile interface with decent support for catching clients up to the
state of the conversation in the face of the intermittent connectivity.

Bouncers are just too fiddly, too high a barrier for many people to bother
with.  I say this as a longtime user of ssh+[screen|tmux]+irssi (which I am
including, somewhat inexactly, into the same broad category as bouncers) so
it's my acknowledging others' experience, as a possible limit to our
outreach, not my own preference.

The way I learned how to use IRC I have to consider possibly being what
Sumana Harihareswara (using Betsy Leondar-Wright's term) calls an
"inessential weirdness":

 https://media.libreplanet.org/u/libreplanet/m/inessential-weirdnesses-in-free-software/

 https://www.harihareswara.net/libreplanet-2016-inessential-weirdnesses-in-free-software.txt

That said, I continue to look to bridges of various kinds for the ability to
continue to use IRC this way without requiring others to make a Hobson's
choice about talking to me using *some* kind of instant messaging.  And so,
on to the details ...

> Quoting Walter Bender (2017-01-17 22:57:22)
> > There is also matrix.org, which is FOSS AFAIK and seems to let one 
> > integrate irc with other channels people may prefer. I suggest a few 
> > passionate community members give some of these systems a test-drive 
> > and then convince us old-timers that we ought to learn some new 
> > tricks.
> 
> The OFTC.net irc channel #debian-in where I hang out recently did 
> several tests with bridging multiple chat systems - irc and Jabber and 
> matrix.org.
> 
> Old-timers like me got frustrated when a bridge was setup where Jabber 
> users appeared in irc not as individual users but as a bot echoing 
> messages from a Jabber room. 
[...]
> Another bridge between irc and matrix.org was tested, better but now 
> each participant had duplicate nicks, with the matrix.org connection 
> having a "[m]" suffix.
> 
> Neither of those to me annoying bridges was setup by me so I don't know 
> the details of the software used.  I can ask, if really interested.

Our hackerspace has been using some Slack integration with our IRC channel
for some time now:

 irc://chat.freenode.net/#interlock

I find the lack of transparency beyond the bridge to be very annoying, too,
and I have not been using the Slack side of it, given the various
freedom-impacting infelicities of Slack.

Our FOSS program at RIT has a Telegram bridge to its IRC channel:

 irc://chat.freenode.net/#interlock

It suffers a similar lack of transparency across the bridge, and because it
is also not end-to-end free (the Telegram server is not free), I've not been
using the Telegram side of it.

What's worse, I cannot remember in which of those two channels I must
prepend an @ in order to highlight someone on the other side of the bridge
(assuming I can gather what name they use on that bridge based on
backscroll). So, complications multiply.

In comparison to both of these cases, we are using the matrix.org
homeserver's freenode integration in both channels. It does, in fact, put
two nicks in the channel for that person, but this to me is a
straightforward indication that the Matrix integration is effected through a
per-person bot, run from the homeserver side of the connection on behalf of
that user. If the user keeps their Matrix username consistent with their IRC
nick, they can receive highlights with no additional effort on IRC users'
part, despite the [m] suffix. When there is a netsplit between the matrix
homeserver and the ircd, you can tell in a way that other kinds of bridging
would not so cleanly be able to show.

I've mucked around with various XMPP things over the years, including
currently running my own ejabberd and using bitlbee as an XMPP<-->IRC
connector for some private personal groupchats, and with multiple Android
devices to connect to those groupchats. It might be that I'm doing something
wrong, but I have never had very good luck using a single XMPP account
across multiple devices--traffic will go to one or another but not all of
them, depending on what sort of connectivity state they've fallen into. 

With Matrix, that "Just Works" such that I see a consistent view of the
conversation on any device or client I've used so far.  Even so, XMPP and
its software implementations seem to be under continued development and I am
keeping my eye on it.
 
> A third bridge that looks promising is Biboumi.  We tested only briefly 
> so far but it looks like it properly represents each participant without 
> a visible bot in-between or dublicated nicks.

I don't know when I'll have the time, but I do mean to give
Biboumi a deeper look as it might be the XMPP<-->IRC solution I've been
looking for.

The other thing that keeps me interested in XMPP and Matrix is that both
development communities have recently adopted the double-ratchet mechanism
to offer the option of doing end-to-end encryption, offered most famously
perhaps by Signal but also WhatsApp (both of which are only practically
available via non-federated, single-vendor, non-free [or non-freeable]
infrastructure).

As a final caveat about tolerating bridges, I'll just note that there's been
a big move towards Signal by a portion of our hackerspace community, and I
only ever hear about anything from that, at best, secondhand since I'm not
using Signal.

I much prefer the annoyances of bridging to that.

-- 
Joe   On ceding power to tech companies: http://xkcd.com/1118/
man screen | grep -A2 weird
  A weird imagination is most useful to gain full advantage of
  all the features.