Re: GitLab migration status and roadmap

[Hashem nolastname]

I've deployed a docker gitlab instance for my workplace. We also struggled
with poor performance.
Gitlab 9.5 has made things noticeably better. What also helped greatly was
increasing the RAM allocated to the machine.

On Fri, Aug 25, 2017 at 10:45 AM, Carlos Soriano  wrote:

> Just a quick update about performance. Seems their "performance team" is
> starting to bring some results, in the last release they report
> improvements in several places. You can take a look at
> https://about.gitlab.com/2017/08/22/gitlab-9-5-released/#performance-
> improvements
>
> Cheers,
> Carlos Soriano
>
> On Tue, Aug 15, 2017 at 5:54 PM, Olav Vitters  wrote:
>
>> On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote:
>> > Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools,
>> is
>> > up to the maintainer what to do with them.
>>
>> Note that this script has a lot of things it does NOT handle. As agreed
>> with Alberto I'm going to fork this into a better script.
>>
>> Basic things like:
>> - ensuring old bugs correctly link to new bugs (bugzilla 123 -> github
>>   something)
>> - links from existing comments to other bugs (comment specifying
>>   bugzilla 123... which now could be anywhere)
>> - migrate users
>> - ensure users still get notifications on their open bugs
>> - what to do with e.g. keywords
>>
>> are not handled by the current script.
>>
>> Note this is not a complaint as I agreed to work on this.
>>
>> --
>> Regards,
>> Olav
>>
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Iterative API design (Was: Re: Matrix as a replacement for Telepathy)

[Sébastien Wilmet]

On Fri, Aug 25, 2017 at 10:21:07AM -0500, Gary Kramlich wrote:
> > Release 3.0? :)
> 
> I know, need more hours in the day :-/  I'll spend some time this
> putting together a 3.0 checklist, but it's not going to be pretty..
> 
> > Seriously, all that nice GObjectification cleanup does make it a nicer
> > proposal as a GNOME framework.
> 
> Yeah, unfortunately it's incomplete, and if we release now, we're just
> going to have a super long 4.0 cycle too.  I'd rather get through 3.0
> get the GObject based API stable and complete and then get into a
> normal development cycle of feature releases again.

To avoid being stuck for years with non-optimal APIs, what I do in Tepl
is to release a new major parallel-installable version every 6 months if
needed (and up until now it *was* needed, but it's a recent library).

For more details, see the section "Iterative API design and stability
guarantees" at:
https://developer.gnome.org/tepl/unstable/intro.html

Maybe Linux distro packagers don't really like that, but I think what is
more important is that in a few years the library is still relevant,
with good APIs. If the GObjectification takes several cycles, no
problem, the API doesn't need to be perfect all the time, it should be
an iterative process, with frequent releases (e.g. every 6 months), to
apply the agile methodology.

For porting applications to the new versions of the library, I think
it's even easier with more frequent API breaks, because if there is a
huge list of API breaks all at once, it's more difficult to port an
application (a huge commit is necassary just to be able to compile the
code again without errors). Basically, if it hurts, do it more often (if
it is necessary):
https://martinfowler.com/bliki/FrequencyReducesDifficulty.html

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[David Woodhouse]

On Fri, 2017-08-25 at 19:13 +0100, Matthew Hodgson wrote:
> Correct, it's nothing like running a Bitlbee.  The typical starting
> point is to use an existing hosted bridge to the protocol of your
> choice that someone is running (e.g. matrix.org or disroot.org). 
> Obviously this means trusting that server with your account on that
> network, but one can always go and run one's own (which means running
> your own server & bridge somewhere - similar complexity to running an
> ircd + ircservices).

Well, my primary use cases are Lync, which authenticates with my local
Kerberos TGT and thus I'd need to be running the server & bridge on my
own laptop, and internal IRC where I suppose I could live with running
a server *somewhere* in the corporate network.

But for the naïve user case, that doesn't really seem like a step
forward. Matrix as just one protocol that's supported, sure. But it
doesn't seem to fill the gap that Telepathy or libpurple do.

smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Matthew Hodgson]

On 25/08/2017 18:51, David Woodhouse wrote:


On Fri, 2017-08-25 at 17:43 +0100, Matthew Hodgson wrote:

Just to be clear, Matrix is *not* trying to be a
one-protocol-to-rule-them-all, any more than libpurple is trying to be
one-API-to-rule-them-all.  Matrix is just doing the same thing:
abstracting multiple networks behind a single API.  The difference to
libpurple is that the abstraction happens serverside by default rather
than clientside.

(Although we do have matrix-appservice-purple, which uses libpurple
serverside as a way to bridge to other networks, a bit like bitlbee but
talking Matrix on the frontend rather than IRC).

What is the user experience here? Not like users being expected to do
something "a bit like" setting up bitlbee, one hopes? :)


Correct, it's nothing like running a Bitlbee.  The typical starting 
point is to use an existing hosted bridge to the protocol of your choice 
that someone is running (e.g. matrix.org or disroot.org).  Obviously 
this means trusting that server with your account on that network, but 
one can always go and run one's own (which means running your own server 
& bridge somewhere - similar complexity to running an ircd + ircservices).


If you're using an existing bridge, the easiest bet is to use an app 
like Riot which has UI for discovering chatrooms & users on bridged 
networks.  For instance 
https://matrix.org/_matrix/media/v1/download/matrix.org/CYonYNicRBvaiBwzKiuQUjSc 
shows a screenshot of the available bridged networks on the matrix.org 
server (a mix of IRC and Gitter for now).  There is also UI to go and 
provision a bridge through to a specific Slack or Twitter feed.


So the end result is that you end up with always-on connections to the 
various networks, provided by Matrix acting as a decentralised bouncer 
on steroids, with a very simple HTTP API (better transports are welcome 
though) for interaction, which any app could use.


My proposal is that one could run a background daemon on Linux which 
brokered the connection to your Matrix server (and perhaps handled fun 
stuff like clientside history persistence, e2e encryption voodoo, WebRTC 
audio playback/capture etc) and then expose that as part of the OS to 
desktop apps - effectively as a next gen telepathy equivalent.  (And 
yes, such a daemon could be extended to natively talk other protocols 
than Matrix if desired).



If I've got this shiny new Matrix-replaces-Telepathy GNOME system, and
I want to add a new account with a new protocol... what do I need to
do? Let's assume I've just installed the appropriate distro package,
and want to take it from there. (Although do feel free to talk about
how it auto-installs the correct protocol package on demand, if you
prefer).


Hypothetically: you'd do as per the above; install a package for a 
client like Riot; point it at a server which is providing a bunch of 
bridges (or go hunt bridges on other servers); or go run your own bridge 
on your own server.  For some bridges you need to login/identify (which 
is handled on a per-bridge basis currently) - the naive approach some 
bridges take atm is to do it a la Nickserv (i.e you have a conversation 
with a bot); in future there will be better reusable OAuth style UI for 
logging in.


I should point out that Matrix is still in beta (especially bridging), 
though, so I'm not claiming it's a universal solution - and I really do 
agree that having libpurple and similar around too clientside makes 
sense.  But having access to a decentralised encrypted comms network 
from the OS does also feel like a useful primitive to have available too :)


M

--
Matthew Hodgson
Matrix.org

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Sébastien Wilmet]

On Fri, Aug 25, 2017 at 11:28:34AM -0500, Michael Catanzaro wrote:
> I think what's clear right now is that Telepathy has no future and should be
> immediately removed from our stack. We should have done that years ago when
> maintenance ceased.

Maybe Telepathy and Empathy have utility/self-contained classes or
functions that would be worthwhile to keep. To ease the implementation
of a new protocol, or to have some re-usable building blocks for the
GUI. With the library written more as a toolkit, not a framework.

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[David Woodhouse]

On Fri, 2017-08-25 at 17:43 +0100, Matthew Hodgson wrote:
> 
> Just to be clear, Matrix is *not* trying to be a 
> one-protocol-to-rule-them-all, any more than libpurple is trying to be 
> one-API-to-rule-them-all.  Matrix is just doing the same thing: 
> abstracting multiple networks behind a single API.  The difference to 
> libpurple is that the abstraction happens serverside by default rather 
> than clientside.
> 
> (Although we do have matrix-appservice-purple, which uses libpurple 
> serverside as a way to bridge to other networks, a bit like bitlbee but 
> talking Matrix on the frontend rather than IRC).

What is the user experience here? Not like users being expected to do
something "a bit like" setting up bitlbee, one hopes? :)

If I've got this shiny new Matrix-replaces-Telepathy GNOME system, and
I want to add a new account with a new protocol... what do I need to
do? Let's assume I've just installed the appropriate distro package,
and want to take it from there. (Although do feel free to talk about
how it auto-installs the correct protocol package on demand, if you
prefer).

smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Michael Catanzaro]

On Thu, Aug 24, 2017 at 3:40 PM, Sriram Ramkrishna  
wrote:
What do people think about integrating directly with Matrix as a 
replacement for Telepathy?


I think what's clear right now is that Telepathy has no future and 
should be immediately removed from our stack. We should have done that 
years ago when maintenance ceased.


I don't think we need to discuss what, if anything, should replace it 
right now. The community consensus seems to be Matrix, and I'm hoping 
to see a successful GNOME Matrix client in the near future. I know 
there are multiple efforts at to make one right now. But people are 
clearly working on libpurple too, and that's fine. We can let it play 
out and decide in a couple of years if or how we want to bring back 
desktop integration for chat. In the meantime, as a longtime Empathy 
user and a recent convert to Polari, the current state of Telepathy 
integration in gnome-shell is not valuable to me.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Gary Kramlich]

On Fri, Aug 25, 2017 at 10:55 AM, David Woodhouse  wrote:
> On Fri, 2017-08-25 at 10:21 -0500, Gary Kramlich wrote:
>> > It's also a little hard to add the new features that we need, as things
>> > stand. I actually ended up backporting a bunch of stuff from 3.x to the
>> > 2.x branch a while back, to support everything that Lync needed. I'm
>> > kind of resigned to the fact that I might need to do the same, for the
>> > protocol I'm working on now.
>>
>> Dang, well let me know where I can help.
>
> Thanks.
>
> I think you've actually already done the most useful thing, which is to
> give me commit access and tell me to go ahead and backport the missing
> features to 2.x that I needed. That meant that the lack of a 3.0
> release didn't actually prevent me from being able to ship those
> features at all.
>
> Obviously where I'd want to *change* an API rather than adding one,
> that approach is more complicated, but we've been able to cope so far.
>
> At some point I need to reinstate my access now that the repo has moved
> to bitbucket, and then I can start submitting patches for review again.

We've just been doing the forking model and saving direct commits to
the main repo for extreme circumstances.  Ie: tagging and other weird
stuff.

> On the whole, I quite like the idea of switching from Telepathy to
> libpurple. Much more than assuming a one-protocol-to-rule-them-all
> approach.

Me too, but of course I'm biased ;)

> --
> dwmw2


Thanks,

--
Gary Kramlich 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[David Woodhouse]

On Fri, 2017-08-25 at 10:21 -0500, Gary Kramlich wrote:
> > It's also a little hard to add the new features that we need, as things
> > stand. I actually ended up backporting a bunch of stuff from 3.x to the
> > 2.x branch a while back, to support everything that Lync needed. I'm
> > kind of resigned to the fact that I might need to do the same, for the
> > protocol I'm working on now.
>
> Dang, well let me know where I can help.

Thanks.

I think you've actually already done the most useful thing, which is to
give me commit access and tell me to go ahead and backport the missing
features to 2.x that I needed. That meant that the lack of a 3.0
release didn't actually prevent me from being able to ship those
features at all.

Obviously where I'd want to *change* an API rather than adding one,
that approach is more complicated, but we've been able to cope so far.

At some point I need to reinstate my access now that the repo has moved
to bitbucket, and then I can start submitting patches for review again.

On the whole, I quite like the idea of switching from Telepathy to
libpurple. Much more than assuming a one-protocol-to-rule-them-all
approach.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Alexandre Franke]

On Fri, Aug 25, 2017 at 5:13 PM, Tomasz Torcz  wrote:
>   It didn't save XMPP, why would this design results in different fate with 
> Matrix?

https://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-xmpp

-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Tomasz Torcz]

On Fri, Aug 25, 2017 at 03:19:34PM +0300, Adrian Perez de Castro wrote:
> While in many respects I like a lot some of the ideas behind Telepahy, and for
> example the seamless integration of third-party IM providers in the N900/N9
> was outstanding, there is one major drawback: Making all CMs fit into the
> common set of features of all the supported ends up providing a suboptimal
> user experience (sometimes vastly inferior). This is one of the reasons why
> Empathy was always very mediocre at supporting XMPP and I for many things I
> ended up finding myself using Gajim when I was an avid XMPP user.
> 
> On the other hand, by adopting Matrix we have the chance of providing an
> exceptional native UX at a potentially much smaller development cost by
> focusing on a single protocol [1] — and Matrix itself connecting to
> third-party services, instead of trying to solve the fragmentation in the
> client-side with subpar solutions.


  That's kinda ironic, as XMPP was Matrix of its time.  There was connectivity
to other (proprietary) IM networks through server-side “transports”. Client 
implementing
XMPP only was able to chat with ICQ, GG, MSN, IRC and others – via transports.

  It didn't save XMPP, why would this design results in different fate with 
Matrix?

-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Gary Kramlich]

On Fri, Aug 25, 2017 at 10:13 AM, David Woodhouse  wrote:
> On Fri, 2017-08-25 at 09:51 -0500, Gary Kramlich wrote:
>> >
>> > On Fri, Aug 25, 2017 at 3:59 PM, David Woodhouse  wrote:
>> > >
>> > > On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote:
>> > > >
>> > > > If someone cares enough to implement support for a protocol in
>> > > > Telepathy, they could probably implement support for the protocol
>> > > > elsewhere too.
>> > > But where is "elsewhere"? If not libpurple, where *should* I be adding
>> > > support for my new toy protocol for example? If you've just taken your
>> > > ball and gone home...
>> >
>> > Well why not libpurple?
>>
>> As the current lead developer of Pidgin, and thus libpurple, I would
>> love to see more people using it.  if there's something we can do to
>> make Pidgin/libpurple a stronger contender in this race, please let me
>> know.
>
> Release 3.0? :)

I know, need more hours in the day :-/  I'll spend some time this
putting together a 3.0 checklist, but it's not going to be pretty..

> Seriously, all that nice GObjectification cleanup does make it a nicer
> proposal as a GNOME framework.

Yeah, unfortunately it's incomplete, and if we release now, we're just
going to have a super long 4.0 cycle too.  I'd rather get through 3.0
get the GObject based API stable and complete and then get into a
normal development cycle of feature releases again.

> It's also a little hard to add the new features that we need, as things
> stand. I actually ended up backporting a bunch of stuff from 3.x to the
> 2.x branch a while back, to support everything that Lync needed. I'm
> kind of resigned to the fact that I might need to do the same, for the
> protocol I'm working on now.

Dang, well let me know where I can help.

> But overall, I think libpurple does a fairly good job, even if it needs
> a little updating to handle the needs of some new protocols.

Thanks!

>> Your critiques about needing updates for newer protocols are certainly
>> valid, and we're slowly marching towards them as we're trying to
>> modernize our codebase.  That said if anyone would like to discuss
>> them in more detail, I'd love to hear it (off list naturally).
>
> For my part I haven't quite got there yet. I'm filling in the parts of
> the protocol support that libpurple *can* represent, before I turn to
> the bits I actually want to extend libpurple for.

Understood.

> Top of my list will be persistent messages, read receipts and multi-way
> V/V calls though. And I've already been asking on the devel list about
> why Pidgin has no way to display presence status or full names for an
> "unknown" person who sends me an IM, even though my prpl has it and
> could tell you.

Noted.

Thanks,

--
Gary Kramlich 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[David Woodhouse]

On Fri, 2017-08-25 at 09:51 -0500, Gary Kramlich wrote:
> > 
> > On Fri, Aug 25, 2017 at 3:59 PM, David Woodhouse  wrote:
> > > 
> > > On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote:
> > > > 
> > > > If someone cares enough to implement support for a protocol in
> > > > Telepathy, they could probably implement support for the protocol
> > > > elsewhere too.
> > > But where is "elsewhere"? If not libpurple, where *should* I be adding
> > > support for my new toy protocol for example? If you've just taken your
> > > ball and gone home...
> >
> > Well why not libpurple?
>
> As the current lead developer of Pidgin, and thus libpurple, I would
> love to see more people using it.  if there's something we can do to
> make Pidgin/libpurple a stronger contender in this race, please let me
> know.

Release 3.0? :)

Seriously, all that nice GObjectification cleanup does make it a nicer
proposal as a GNOME framework.

It's also a little hard to add the new features that we need, as things
stand. I actually ended up backporting a bunch of stuff from 3.x to the
2.x branch a while back, to support everything that Lync needed. I'm
kind of resigned to the fact that I might need to do the same, for the
protocol I'm working on now.

But overall, I think libpurple does a fairly good job, even if it needs
a little updating to handle the needs of some new protocols.

> Your critiques about needing updates for newer protocols are certainly
> valid, and we're slowly marching towards them as we're trying to
> modernize our codebase.  That said if anyone would like to discuss
> them in more detail, I'd love to hear it (off list naturally).

For my part I haven't quite got there yet. I'm filling in the parts of
the protocol support that libpurple *can* represent, before I turn to
the bits I actually want to extend libpurple for.

Top of my list will be persistent messages, read receipts and multi-way 
V/V calls though. And I've already been asking on the devel list about
why Pidgin has no way to display presence status or full names for an
"unknown" person who sends me an IM, even though my prpl has it and
could tell you.

smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Gary Kramlich]

> On Fri, Aug 25, 2017 at 3:59 PM, David Woodhouse  wrote:
>> On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote:
>>> If someone cares enough to implement support for a protocol in
>>> Telepathy, they could probably implement support for the protocol
>>> elsewhere too.
>>
>> But where is "elsewhere"? If not libpurple, where *should* I be adding
>> support for my new toy protocol for example? If you've just taken your
>> ball and gone home...
>
> Well why not libpurple?

As the current lead developer of Pidgin, and thus libpurple, I would
love to see more people using it.  if there's something we can do to
make Pidgin/libpurple a stronger contender in this race, please let me
know.

Your critiques about needing updates for newer protocols are certainly
valid, and we're slowly marching towards them as we're trying to
modernize our codebase.  That said if anyone would like to discuss
them in more detail, I'd love to hear it (off list naturally).

> --
> Alexandre Franke
> GNOME Hacker & Foundation Director

Thanks,

--
Gary Kramlich 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab migration status and roadmap

[Carlos Soriano]

Just a quick update about performance. Seems their "performance team" is
starting to bring some results, in the last release they report
improvements in several places. You can take a look at
https://about.gitlab.com/2017/08/22/gitlab-9-5-released/#performance-improvements

Cheers,
Carlos Soriano

On Tue, Aug 15, 2017 at 5:54 PM, Olav Vitters  wrote:

> On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote:
> > Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools,
> is
> > up to the maintainer what to do with them.
>
> Note that this script has a lot of things it does NOT handle. As agreed
> with Alberto I'm going to fork this into a better script.
>
> Basic things like:
> - ensuring old bugs correctly link to new bugs (bugzilla 123 -> github
>   something)
> - links from existing comments to other bugs (comment specifying
>   bugzilla 123... which now could be anywhere)
> - migrate users
> - ensure users still get notifications on their open bugs
> - what to do with e.g. keywords
>
> are not handled by the current script.
>
> Note this is not a complaint as I agreed to work on this.
>
> --
> Regards,
> Olav
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Alexandre Franke]

On Fri, Aug 25, 2017 at 3:59 PM, David Woodhouse  wrote:
> On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote:
>> If someone cares enough to implement support for a protocol in
>> Telepathy, they could probably implement support for the protocol
>> elsewhere too.
>
> But where is "elsewhere"? If not libpurple, where *should* I be adding
> support for my new toy protocol for example? If you've just taken your
> ball and gone home...

Well why not libpurple?

-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[David Woodhouse]

On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote:
> On Fri, Aug 25, 2017 at 2:05 PM, David Woodhouse  wrote:
> > But isn't that the *point*? We have a framework with plugins for all
> > manner of different protocols, instead of a mess of separate protocol-
> > specific clients each of which can handle only *one*.
> 
> When the choice is given to me between sticking to an abstraction that
> tries but doesn’t manage to grasp the quirks of several protocols, or
> switching to a protocol specific API and embrace it to make sure it is
> correctly and fully supported, I pick the latter. Even if I have to do
> it twice or more. I don’t think the *point* should be to support
> several protocols badly.

That's very true, and I don't think you're wrong to want a Matrix-
specific UI which doesn't attempt to use Telepathy at all.

I'm just nitpicking that this isn't a "replacement for Telepathy"; it's
rightly ditching Telepathy and just doing your own protocol-specific
thing.

It's slightly suboptimal for *me* because I'm working on protocol
support for Yet Another IM Protocol, as well as occasionally still
prodding at the siplcs Lync support, and really don't want to live in a
world where each protocol needs to put together its *own* GUI to
support it specifically. 

Right now I'm building my toy as a Pidgin/libpurple plugin but not
because I particularly like Pidgin; I think it's fairer to say that I
just hate libpurple less than I hate everything *else*. It also has the
impedance mismatches and doesn't support some of the things I need like
persistent editable messages, read receipts, multi-way V/V calls with
indication of who's speaking at any given moment, etc... but it *could*
be added...

> I also don’t think we should aim at supporting all the protocols that
> exist. I don’t think a single client can map to the features of all of
> them.

Just because it's been done badly/incompletely that doesn't mean it's
impossible.

> If someone cares enough to implement support for a protocol in
> Telepathy, they could probably implement support for the protocol
> elsewhere too.

But where is "elsewhere"? If not libpurple, where *should* I be adding
support for my new toy protocol for example? If you've just taken your
ball and gone home...

smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Matthew Hodgson]

On 25/08/2017 14:10, David Woodhouse wrote:


On Fri, 2017-08-25 at 14:00 +0100, Matthew Hodgson wrote:


 From memory, the sort of modern features which Matrix has which the API 
doesn't handle include:

  * Infinite scrollback serverside history
  * Synced history across multiple devices
  * Server side search
  * Server side notification settings
  * Read receipts
  * Read-up-to markers
  * Multiway voip
  * Promoting 1:1s to group chats and vice versa
  * Native end-to-end encryption (verifying keys, devices, sharing keys, etc)
  * Encrypted file transfers
  * Redacted msgs

  And upcoming shortly:
  * Reactions / upvotes / downvotes
  * Editable msgs
  * Pinned messages
  * Threading

Matrix isn't the only protocol that supports many of those.

I'm no fan of Telepathy, certainly — the complete lack of error
reporting was what caused me to ditch it and stick with Pidgin for
corporate Lync users. When users are completely unaware that they
aren't reachable on IM, or why, that's a total UX fail.

But I still think we're better off with a *generic* framework, even if
we have to drag it into the 21st century, than tying ourselves into a
single protocol.


You do have to consider that Matrix is intended as a generic protocol, 
though.  The reason it's called Matrix is because it tries to matrix 
together as many existing silos as possible - but doing the bridging 
serverside on decentralised bridges.  The best way to sum it up is 
https://twitter.com/matrixdotorg/status/841424770025545730.


That said, I totally agree that such a telepathy replacement should also 
have the option of supporting other protocols natively rather than via 
Matrix bridges.  But it might make sense to take inspiration for the API 
to be similar to Matrix's (given it's been built for the whole purpose 
of abstracting multiple protocols, whether that abstraction is done 
serverside or clientside).




Of course if you want to go and make a lovely shiny UI for your single
protocol, nobody should dissuade you from that. But to talk about it as
a "replacement for Telepathy" doesn't make sense to me.


--
Matthew Hodgson
Matrix.org

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Alexandre Franke]

On Fri, Aug 25, 2017 at 2:05 PM, David Woodhouse  wrote:
> But isn't that the *point*? We have a framework with plugins for all
> manner of different protocols, instead of a mess of separate protocol-
> specific clients each of which can handle only *one*.

When the choice is given to me between sticking to an abstraction that
tries but doesn’t manage to grasp the quirks of several protocols, or
switching to a protocol specific API and embrace it to make sure it is
correctly and fully supported, I pick the latter. Even if I have to do
it twice or more. I don’t think the *point* should be to support
several protocols badly.

I also don’t think we should aim at supporting all the protocols that
exist. I don’t think a single client can map to the features of all of
them.

If someone cares enough to implement support for a protocol in
Telepathy, they could probably implement support for the protocol
elsewhere too.

-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[David Woodhouse]

On Fri, 2017-08-25 at 13:56 +0200, Alexandre Franke wrote:
> On Fri, Aug 25, 2017 at 1:46 PM, Felipe Borges  wrote:
> > 
> > All in all, if desirable, Matrix and GNU Ring could be connection
> > managers in Telepathy instead of standalone bits.
> > 
> > Specific clients could be created backed by Telepathy, e.g. no need to
> > rely on Empathy.
>
> One of the main points of Sri’s proposal is to get rid of Telepathy.
> Its architecture is a burden and e.g. Polari has problems because of
> the extra layers that wouldn’t exist if it talked to IRC directly.

But isn't that the *point*? We have a framework with plugins for all
manner of different protocols, instead of a mess of separate protocol-
specific clients each of which can handle only *one*.

smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[David Woodhouse]

On Fri, 2017-08-25 at 14:00 +0100, Matthew Hodgson wrote:

> From memory, the sort of modern features which Matrix has which the API 
> doesn't handle include:
> 
>  * Infinite scrollback serverside history
>  * Synced history across multiple devices
>  * Server side search
>  * Server side notification settings 
>  * Read receipts
>  * Read-up-to markers
>  * Multiway voip
>  * Promoting 1:1s to group chats and vice versa
>  * Native end-to-end encryption (verifying keys, devices, sharing keys, etc)
>  * Encrypted file transfers
>  * Redacted msgs
> 
>  And upcoming shortly:
>  * Reactions / upvotes / downvotes 
>  * Editable msgs
>  * Pinned messages
>  * Threading

Matrix isn't the only protocol that supports many of those.

I'm no fan of Telepathy, certainly — the complete lack of error
reporting was what caused me to ditch it and stick with Pidgin for
corporate Lync users. When users are completely unaware that they
aren't reachable on IM, or why, that's a total UX fail.

But I still think we're better off with a *generic* framework, even if
we have to drag it into the 21st century, than tying ourselves into a
single protocol.

Of course if you want to go and make a lovely shiny UI for your single
protocol, nobody should dissuade you from that. But to talk about it as
a "replacement for Telepathy" doesn't make sense to me.


smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Matthew Hodgson]

-- 
Matthew Hodgson
Matrix.org
> On 25 Aug 2017, at 12:46, Felipe Borges  wrote:
> 
>> On Fri, Aug 25, 2017 at 12:15 AM, Alejandro HC  wrote:
>> A comment as a user. Since Empathy ceased to be maintained, there has been
>> little concern for the communication system that is available in gnome
>> focused to end user (gnome-polari is targeted to IRC which is mostly used by
>> developer communities).
>> 
>> Matrix is great, but I feel it points to the same, so why not support GNU
>> Ring in GNOME ... Ring is a project that aims to be a free replacement for
>> Skype, in addition already has a good integration in gnome and it's easy to
>> use, offering its own communication protocol it offers support for SIP.
> 
> Telepathy was designed as a framework which could have various
> "Connection Managers" (in the telepathy terminology). A Connection
> Manager is responsible of doing the actual communication with a given
> server through a given protocol. Telepathy has connection managers for
> XMPP, SIP, IRC, etc... see [0]. For instance, Polari uses Telepathy
> for the IRC protocol.

Folks have looked at building a telepathy connection manager for Matrix in the 
past (starting with https://github.com/gergelypolonkai/matrix-glib-sdk and 
working outwards), but rapidly hit major impedance mismatches with telepathy's 
API which sadly dates back to a simpler age of IRCv2 and 1st generation IM apps 
like ICQ or MSN.

From memory, the sort of modern features which Matrix has which the API doesn't 
handle include:

 * Infinite scrollback serverside history
 * Synced history across multiple devices
 * Server side search
 * Server side notification settings 
 * Read receipts
 * Read-up-to markers
 * Multiway voip
 * Promoting 1:1s to group chats and vice versa
 * Native end-to-end encryption (verifying keys, devices, sharing keys, etc)
 * Encrypted file transfers
 * Redacted msgs

 And upcoming shortly:
 * Reactions / upvotes / downvotes 
 * Editable msgs
 * Pinned messages
 * Threading

So, the choices are either to build a new version of telepathy with that sort 
of featureset, or build something new which exposes Matrix's API via Dbus or 
similar. One could then use local or remote bridges to other protocols (or 
follow the "connection mgr" pattern to implement them locally, but given that 
would barely be using Matrix at all it's not really our focus).

M

> 
> All in all, if desirable, Matrix and GNU Ring could be connection
> managers in Telepathy instead of standalone bits.
> 
> Specific clients could be created backed by Telepathy, e.g. no need to
> rely on Empathy.
> 
> [0] https://telepathy.freedesktop.org/components/
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Adrian Perez de Castro]

Hi all,

I wholeheartedly support (+1!) scraping Telepathy and going full-Matrix.

On Fri, 25 Aug 2017 13:56:24 +0200, Alexandre Franke  wrote:
> On Fri, Aug 25, 2017 at 1:46 PM, Felipe Borges  wrote:
> > All in all, if desirable, Matrix and GNU Ring could be connection
> > managers in Telepathy instead of standalone bits.
> >
> > Specific clients could be created backed by Telepathy, e.g. no need to
> > rely on Empathy.
>
> One of the main points of Sri’s proposal is to get rid of Telepathy.
> Its architecture is a burden and e.g. Polari has problems because of
> the extra layers that wouldn’t exist if it talked to IRC directly.

While in many respects I like a lot some of the ideas behind Telepahy, and for
example the seamless integration of third-party IM providers in the N900/N9
was outstanding, there is one major drawback: Making all CMs fit into the
common set of features of all the supported ends up providing a suboptimal
user experience (sometimes vastly inferior). This is one of the reasons why
Empathy was always very mediocre at supporting XMPP and I for many things I
ended up finding myself using Gajim when I was an avid XMPP user.

On the other hand, by adopting Matrix we have the chance of providing an
exceptional native UX at a potentially much smaller development cost by
focusing on a single protocol [1] — and Matrix itself connecting to
third-party services, instead of trying to solve the fragmentation in the
client-side with subpar solutions.

Cheers,


--
 Adrián “Two Cents” Pérez

[1] Like Polari is strivin to do.


pgpT3qi7o7x2g.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Matthew Hodgson]

Matrix is about much more than IRC-style communication, although it's a 
common misunderstanding given most of the popular use of Matrix today 
happens to be as a decentralised IRC/Slack/Gitter/Telegram alternative.


We have Skype-style voice and video calls too, as well as conference 
calls (and as of two days ago, integration with other conferencing 
platforms like Jitsi).  For instance, we've just teamed up with the 
Purism guys to deliver a VoIP/messaging app for their new Librem 5 FLOSS 
smartphone: 
https://matrix.org/blog/2017/08/24/the-librem-5-from-purism-a-matrix-native-smartphone/.


I'm obviously biased, but I think that using Matrix as an alternative to 
Telepathy would be a great idea.  One of the proposed pieces of work for 
the Purism deal in fact would be to run a background Matrix client on 
the phone which can receive Matrix push notifications, inbound messages 
& calls etc, and expose them via DBUS or similar for the rest of the OS 
to use.  Thus applications could either talk HTTP direct to their 
preferred Matrix server, or use a Matrix-over-DBUS style API to share 
the same daemon across all apps.  This could also be super-useful for 
E2E crypto, as the heavy lifting crypto work could be done by a shared 
daemon, and expose a simple plaintext API through to the client apps on 
the machine itself (assuming you trusted the host sufficiently).


This work is currently a stretch goal for the Purism campaign though if 
they significantly overshoot their funding target, so if the wider GNOME 
or Matrix or Linux community was interested in pursuing this sooner than 
later it would only be a Good Thing.


thanks,

Matthew

On 24/08/2017 23:15, Alejandro HC wrote:

A comment as a user. Since Empathy ceased to be maintained, there has
 been little concern for the communication system that is available
in gnome focused to end user (gnome-polari is targeted to IRC which
is mostly used by developer communities).

Matrix is great, but I feel it points to the same, so why not support
 GNU Ring in GNOME ... Ring is a project that aims to be a free 
replacement for Skype, in addition already has a good integration in

 gnome and it's easy to use, offering its own communication protocol
it offers support for SIP.

2017-08-24 17:40 GMT-03:00 Sriram Ramkrishna >:


I thought I would put it out there after some discussion to make sure
it isn't a completely crazy idea.

What do people think about integrating directly with Matrix as a 
replacement for Telepathy?  This would mean that we can focus on 
chat, video-conferencing, and anything else through Matrix.  We'd 
have to abandon clients like empathy (or modify).  For IRC we would 
use our own library or use matrix's bridge.


This way, we can push this support to an upstream that cares and is 
culturally compatible with us.  Matrix of course gets a boost from a 
major group relying on them and providing alternative clients and a 
superior (hopefully) user experience.


sri

___ desktop-devel-list
mailing list desktop-devel-list@gnome.org
 
https://mail.gnome.org/mailman/listinfo/desktop-devel-list 






-- *Hugo*

___ desktop-devel-list
mailing list desktop-devel-list@gnome.org 
https://mail.gnome.org/mailman/listinfo/desktop-devel-list




--
Matthew Hodgson
Matrix.org
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Alexandre Franke]

On Fri, Aug 25, 2017 at 1:46 PM, Felipe Borges  wrote:
> All in all, if desirable, Matrix and GNU Ring could be connection
> managers in Telepathy instead of standalone bits.
>
> Specific clients could be created backed by Telepathy, e.g. no need to
> rely on Empathy.

One of the main points of Sri’s proposal is to get rid of Telepathy.
Its architecture is a burden and e.g. Polari has problems because of
the extra layers that wouldn’t exist if it talked to IRC directly.

-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Matrix as a replacement for Telepathy

[Felipe Borges]

On Fri, Aug 25, 2017 at 12:15 AM, Alejandro HC  wrote:
> A comment as a user. Since Empathy ceased to be maintained, there has been
> little concern for the communication system that is available in gnome
> focused to end user (gnome-polari is targeted to IRC which is mostly used by
> developer communities).
>
> Matrix is great, but I feel it points to the same, so why not support GNU
> Ring in GNOME ... Ring is a project that aims to be a free replacement for
> Skype, in addition already has a good integration in gnome and it's easy to
> use, offering its own communication protocol it offers support for SIP.

Telepathy was designed as a framework which could have various
"Connection Managers" (in the telepathy terminology). A Connection
Manager is responsible of doing the actual communication with a given
server through a given protocol. Telepathy has connection managers for
XMPP, SIP, IRC, etc... see [0]. For instance, Polari uses Telepathy
for the IRC protocol.

All in all, if desirable, Matrix and GNU Ring could be connection
managers in Telepathy instead of standalone bits.

Specific clients could be created backed by Telepathy, e.g. no need to
rely on Empathy.

[0] https://telepathy.freedesktop.org/components/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list