Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to connect to remote weechat relays #369

Open
moopie opened this Issue Mar 22, 2015 · 53 comments

Comments

Projects
None yet
@moopie
Copy link

moopie commented Mar 22, 2015

Would be nice to be able to use weechat relays through the client itself.

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Mar 22, 2015

For now this feature is not planned.
You could run WeeChat under screen or tmux, and it's even better than using an extra network layer, with limited features (the protocol will not let you do exactly same things than in WeeChat itself).

@fuzzy76

This comment has been minimized.

Copy link

fuzzy76 commented May 12, 2015

But it does not let you interact with the local terminal.

@x89

This comment has been minimized.

Copy link

x89 commented May 12, 2015

Not sure what you mean @fuzzy76? You can add a /relay weechat and then connect (for example via the Android app) and it has all your buffers on it.

It would be nice if you could do this from another linux machine. The alternative at the moment is adding /relay add freenode bla bla bla and on the client adding /server add freenode <serverip>.

Am I missing something?

@fuzzy76

This comment has been minimized.

Copy link

fuzzy76 commented May 12, 2015

The original issue explained it nicely. :) This issue is about connecting to a weechat relay WITH a weechat client.

@Quantum-cross

This comment has been minimized.

Copy link

Quantum-cross commented May 30, 2015

I would also like this feature. I like that the weechat protocol supports full buffer syncing, and I also like the weechat curses interface.

@carnager

This comment has been minimized.

Copy link

carnager commented Jul 20, 2015

This seems a rather strange limitation. A program implements a completely new protocol and is not able to interpret it.

Definitely would like to see this.

@bastelfreak

This comment has been minimized.

Copy link

bastelfreak commented Jul 20, 2015

👍 +1 for this, would be a really helpful feature.

@gitdings

This comment has been minimized.

Copy link

gitdings commented Aug 22, 2015

+1 for this. It would indeed be a great and wonderful feature that'd make the (weechat-) world even better.

@ehwat

This comment has been minimized.

Copy link

ehwat commented Jan 5, 2016

👍

@jreinert

This comment has been minimized.

Copy link

jreinert commented Jan 5, 2016

+1 makes no sense to me why this hasn't been implemented

@bastelfreak

This comment has been minimized.

Copy link

bastelfreak commented Jan 5, 2016

Hi @flashcode, do you have any update for us?

@Nokogiri

This comment has been minimized.

Copy link

Nokogiri commented Jan 5, 2016

+1

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jan 6, 2016

Issue is still open and not marked as "won't fix", so this could be implemented in far future.

"Far future" because it's not quick and easy task to add that, following features must be added:

  1. decoding of WeeChat protocol (not so easy, even if the reverse (encode data) for clients is already implemented), especially because as far as I know, no C client currently implements that
  2. add a new network layer in relay plugin to act as a "client": connect to a remote host, like it's done in irc plugin, and manage network problems (reconnection, resynchronization with remote relay, ...)
  3. manage "relay servers", like irc servers, ie being able to define multiple WeeChat relays with different addresses/properties and auto-connect to them on startup (this feature is not mandatory in a first step though)
  4. create new relay buffers matching the remote WeeChat instance ; and as I said previously, this could work but in a limited way because these buffers will not be exactly the same as real irc buffers (completion will not be as smart as irc buffer, scripts will not interact properly with these buffers, etc...).
@fuzzy76

This comment has been minimized.

Copy link

fuzzy76 commented Jan 6, 2016

That sounds like a whole lot of plumbing for a client that already is supposed to have multi-protocol architecture according to the featurelist.

@anarcat

This comment has been minimized.

Copy link

anarcat commented Aug 11, 2016

for me the key feature here is the ability to connect to N servers without having to configure N relays, N ssh port forwards/firewall holes, N passwords and so on. it's a big annoyance in the current irssi proxy code as well, and I was hoping that weechat's protocol would mean that this would be solved.

i am also surprised that weechat doesn't fully implement its own protocol, in other words. :)

and yes, tmux/screen/dvtm kind of do what we want here, but they have their own set of issues, mostly with latency and non-local environments that make desktop notifications and similar needlessly difficult to implement. mosh resolves the latency issues, but not the others (and has its own terminal compatibility issues).

so it would be great to see this implemented!

@sixtyfive

This comment has been minimized.

Copy link

sixtyfive commented Sep 9, 2016

Wow, I was surprised to find this issue. I'm a user of the standard ssh > tmux > weechat chain, which keeps me happy at home or in other places having a reliable internet connection. I'd always thought that there would be a way to connect through my existing Weechat buffers running on the server through SSH plus a Weechat client running on my laptop. Now I'm sitting on a train with only a spotty internet connection, but no dice. Not sure if the devs can see this as a valid use case (call me Alice or Bob if you'd like :) ). In any case, big, fat, +1!

@weechatter

This comment has been minimized.

Copy link
Contributor

weechatter commented Sep 10, 2016

try mosh with tmux.

@Phyks

This comment has been minimized.

Copy link

Phyks commented Oct 12, 2016

Mosh with tmux is not a valid solution in my opinion. When you have a laggy internet connection, you really want to type locally and send complete messages, and not only use mosh prediction. Typically, when I have a laggy connection, I want to type consecutive messages, and rely on my client to try to send them indefinitely, till it succeeds, while I am still typing next messages. Plus mosh adds an extra layer which is an overhead to install and maintain.

@flashcode (about #369 (comment)) I am not at all familiar with Weechat internals and management of protocols, but why would it have to be written in C, and be in Weechat core? Wouldn't it be possible to write it as a Weechat module in Python, similarly to what is done for jabber or slack?

EDIT: After thinking a bit more about it, I think I got it. @flashcode above is talking about replicating a full ssh+screen+weechat experience in a local weechat using the weechat relay protocol. This is indeed a lot of work, and I am not sure it is actually needed.
For the use case I have in mind, I just would like to see a basic support for Weechat relay protocol in Weechat, so that a Weechat instance could be used as a basic Weechat relay client. Just the same thing as GB does, except that it would be powered by a local Weechat, and would benefits for all the advanced features (buffers manipulation etc) of the local weechat. It seems to me that we only need to write a Python script similar to the Jabber / Slack ones above to add this support, and such a script would be something like 2k lines of code. I agree this is still a lot of work, but seems much more reasonable.
I am not sure what implementation others in this thread would like, but I am feeling like most of us just want a basic support à la Glowing Bear.

@craftyguy

This comment has been minimized.

Copy link

craftyguy commented Oct 12, 2016

Mosh is also not an option for those of us that have to connect
through proxies, since Mosh screws with ProxyCommand.
On Wed, Oct 12, 2016 at 07:20:31AM -0700, Lucas Verney wrote:

Mosh with tmux is not a valid solution in my opinion. When you have a laggy internet connection, you really want to type locally and send complete messages, and not only use mosh prediction. Typically, when I have a laggy connection, I want to type consecutive messages, and rely on my client to try to send them indefinitely, till it succeeds, while I am still typing next messages. Plus mosh adds an extra layer and you might be unable to have it on your remote server (contrary to weechat relay which is basically just a port to bind).

@flashcode (about #369 (comment)) I am not at all familiar with Weechat internals and management of protocols, but why would it have to be written in C, and be in Weechat core? Wouldn't it be possible to write it as a Weechat module in Python, similarly to what is done for jabber or slack?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#369 (comment)

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Oct 13, 2016

@Phyks : it's easier to integrate code in the relay plugin, where there's already the code to send data to the client (get data from WeeChat, compress, and send). So some parts of code could be reused for the decoding part on the other side.

@regnarg

This comment has been minimized.

Copy link

regnarg commented Jan 10, 2017

Seconded. Another problem with the ssh/tmux/whatever solution is when you want to use weechat from two computers with different screen sizes (so a shared tmux session is not viable because the terminals have different sizes).

@anarcat

This comment has been minimized.

Copy link

anarcat commented Mar 21, 2017

note that since 1.0.0, irssi can multiplex multiple proxy connexions over a single port.

@x89

This comment has been minimized.

Copy link

x89 commented Mar 21, 2017

@anarcat

This comment has been minimized.

Copy link

anarcat commented Mar 21, 2017

me, for one, because of this and #928.

@ashkitten

This comment has been minimized.

Copy link

ashkitten commented Apr 3, 2017

This feature would be great to have

@yvan-sraka

This comment has been minimized.

Copy link

yvan-sraka commented May 24, 2017

👍

@acgissues

This comment has been minimized.

Copy link

acgissues commented Jul 12, 2017

Let me up-vote this too. +1

@Wh1t3Fox

This comment has been minimized.

Copy link

Wh1t3Fox commented Jul 23, 2017

+1

@gviscardi

This comment has been minimized.

Copy link

gviscardi commented Jul 24, 2017

Let me add yet another useless +1

@bendem

This comment has been minimized.

Copy link

bendem commented Jul 24, 2017

You should totally use the thumbs up (👍) feature on the first post instead of sending notifications to every single person watching this repository. It's less noise and easier to filter by.

@sixtyfive

This comment has been minimized.

Copy link

sixtyfive commented Jul 24, 2017

And perhaps one of the contributors could delete the +1s thus far (mine included) :-)

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jul 25, 2017

I'm starting the development of an external C library to decode weechat protocol, with a CLI test client.

Once done, I'll add the feature in relay plugin to connect to another running WeeChat using weechat protocol.

This can take some weeks/months, according to my free time, no planned date/version for now.
Stay tuned!

@sixtyfive

This comment has been minimized.

Copy link

sixtyfive commented Jul 25, 2017

Release early, release often ;-) @flashcode

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jul 25, 2017

@sixtyfive: sure, I agree with that. But I never release partial features, or broken things.
But as usual, the development version of relay lib and WeeChat will be available for tests before the final release.

@iKarith

This comment has been minimized.

Copy link

iKarith commented Sep 3, 2017

Color me interested as well. Currently I use znc whose setup is non-trivial and does not lend itself to adding a random network you may or may not use long-term, etc. The znc lives on a machine I can reach out and touch (more easily than I can the machine I'm typing this from actually--it's just out of reach), but the machine I'm typing from is my primary workstation and it always needs to be rebooted to fiddle with kernels or video drivers, so I keep the bouncer running.

I doubt znc is ever going to feel like I'm just using my irc client, because I'm not. Using a relay does, only the relay client isn't just sitting as window 1 inside my primary tmux session like I'd prefer.

@SakiiR

This comment has been minimized.

Copy link

SakiiR commented Oct 31, 2017

+1 a very good feature to make it better than ZNC :)

@yeled

This comment has been minimized.

Copy link

yeled commented Nov 19, 2017

@flashcode will a donation help in finding spare time in your schedule?

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Nov 19, 2017

@yeled: donations help to keep me motivated for features, but unfortunately, they don't add hours to days (if only they could!).
So it will give higher priority, but for now I'm busy on personal things and have currently no time for WeeChat related developments. I should have some free time again in early 2018.

@shibumi

This comment has been minimized.

Copy link

shibumi commented Nov 20, 2017

@yeled I guess that Pull-Requests are always welcome ;)

@vvug

This comment has been minimized.

Copy link

vvug commented Mar 26, 2018

Any chance to see this in the roadmap for 2.2?

Thank you!

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Mar 26, 2018

@vvug: no chances for 2.2. I'm working on the separate lib to communicate with a weechat relay, which should take some time (I made about 20%), and once ready I have to implement the client side for relay in WeeChat itself, using the lib.
So I don't expect all that stuff to be ready before some months, and this mostly depend on my free time (which is low).

Note: I'll publish the very first version of the lib soon, so people can contribute.

@github-cygwin

This comment has been minimized.

Copy link

github-cygwin commented Mar 29, 2018

It seems this will be needed to connect remotely to a weechat relay providing Slack channels via wee_slack.py. Using the irc relay, the Slack channels are not visible.

@Kreijstal

This comment has been minimized.

Copy link

Kreijstal commented Apr 17, 2018

why invent a totally new protocol if you can't read it yourself lmao

@aep

This comment has been minimized.

Copy link

aep commented Jun 12, 2018

could a bounty revive interest here maybe?

@kevinelliott

This comment has been minimized.

Copy link

kevinelliott commented Jul 3, 2018

I think this feature is very important.

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jul 5, 2018

@aep: unfortunately no, I'm just missing some free time (if you can help on that, this would be fine!).
The dev of the new lib is still in progress, I'll publish first version as soon as possible.

@jesse-osiecki

This comment has been minimized.

Copy link

jesse-osiecki commented Jul 20, 2018

I think if we don't fix this, we should at least make it clear in the docs about /relay that the weechat protocol will not work with weechat itself
It's very confusing as a newcomer

@flashcode I'd be interested in helping, though I'm totally unfamliar with the codebase, so I may need a finger pointed in the right direction

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jul 20, 2018

@jesse-osiecki: it is mentioned in the user's guide: https://weechat.org/files/doc/stable/weechat_user.en.html#relay_weechat_protocol

Once I'll publish the first version of the lib to communicate via relay protocol, you'll be able to help on the lib or to integrate it in WeeChat relay plugin.

@khronosschoty

This comment has been minimized.

Copy link

khronosschoty commented Aug 9, 2018

Please add this!

@KristianLyng

This comment has been minimized.

Copy link

KristianLyng commented Jan 15, 2019

I'm hoping to see some movement here. A ...hypothetical use case I see is where you need to connect to an IRC server behind several layers of security, where the client has to run behind similar layers and will not be able to receive incoming connections for, e.g., hooking up a phone. Since most IRC activity would not be bound by such security measures, one could run a second client on the public internet with a regular relay. The more secure client could then make an outgoing connection to the relay so the user would not have to have two clients open at the same time, but instead only has to chose which client to connect to. Which, presumably, would be dictated by whether or not said user is at work or not.

As a bonus, the user would not be reminded of their dark past of having to juggle multiple BitchX-clients to connect to multiple IRC networks.

If,hypothetically, there's anything I can do to speed up this development or make it more motivating, let me know... I'd offer code, but I suspect that would just increase the amount of work needed since I'm not familiar with the code base, but if not...

@shibumi

This comment has been minimized.

Copy link

shibumi commented Feb 25, 2019

Still waiting for this feature and since version 2.4 hopefully with working TOTP.

@weechatter

This comment has been minimized.

Copy link
Contributor

weechatter commented Feb 25, 2019

it does not get faster, even if this issue is pushed ever month.. Please be patience

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Mar 24, 2019

Hey, some news about the development of this feature.

I've just setup and pushed a new repository with the WeeChat Relay library: https://github.com/weechat/weechat-relay

So the next steps are:

  1. use this library in relay plugin, to send messages from WeeChat to clients; so some code will be moved from the relay plugin to the library (target version: 2.5)
  2. add decoding of WeeChat binary messages in the lib (target version: 2.6, but it's in the lib, not WeeChat)
  3. connect to a remote WeeChat in the relay plugin (target version: 2.7 or 2.8)

Note: the target versions are just estimations.
The WeeChat roadmap will be updated according to the work in progress: https://weechat.org/dev/roadmap

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.