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 · 65 comments
Open

Add ability to connect to remote weechat relays #369

moopie opened this issue Mar 22, 2015 · 65 comments

Comments

@moopie
Copy link

@moopie moopie commented Mar 22, 2015

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

@flashcode
Copy link
Member

@flashcode 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
Copy link

@fuzzy76 fuzzy76 commented May 12, 2015

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

@x89
Copy link

@x89 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
Copy link

@fuzzy76 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
Copy link

@Quantum-cross 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
Copy link

@carnager 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
Copy link

@bastelfreak bastelfreak commented Jul 20, 2015

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

@gitdings
Copy link

@gitdings 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
Copy link

@ehwat ehwat commented Jan 5, 2016

👍

@repomaa
Copy link

@repomaa repomaa commented Jan 5, 2016

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

@bastelfreak
Copy link

@bastelfreak bastelfreak commented Jan 5, 2016

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

@Nokogiri
Copy link

@Nokogiri Nokogiri commented Jan 5, 2016

+1

@flashcode
Copy link
Member

@flashcode 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
Copy link

@fuzzy76 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
Copy link

@anarcat 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
Copy link

@sixtyfive 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
Copy link
Contributor

@weechatter weechatter commented Sep 10, 2016

try mosh with tmux.

@Phyks
Copy link

@Phyks 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
Copy link

@craftyguy 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
Copy link
Member

@flashcode 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
Copy link

@regnarg 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
Copy link

@anarcat anarcat commented Mar 21, 2017

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

@x89
Copy link

@x89 x89 commented Mar 21, 2017

@anarcat
Copy link

@anarcat anarcat commented Mar 21, 2017

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

@ashkitten
Copy link

@ashkitten ashkitten commented Apr 3, 2017

This feature would be great to have

@yvan-sraka
Copy link

@yvan-sraka yvan-sraka commented May 24, 2017

👍

@betoissues
Copy link

@betoissues betoissues commented Jul 12, 2017

Let me up-vote this too. +1

@Wh1t3Fox
Copy link

@Wh1t3Fox Wh1t3Fox commented Jul 23, 2017

+1

@gviscardi
Copy link

@gviscardi gviscardi commented Jul 24, 2017

Let me add yet another useless +1

@yeled
Copy link

@yeled yeled commented Nov 19, 2017

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

@flashcode
Copy link
Member

@flashcode 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
Copy link

@shibumi shibumi commented Nov 20, 2017

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

@vvug
Copy link

@vvug vvug commented Mar 26, 2018

Any chance to see this in the roadmap for 2.2?

Thank you!

@flashcode
Copy link
Member

@flashcode 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
Copy link

@github-cygwin 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
Copy link

@Kreijstal Kreijstal commented Apr 17, 2018

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

@aep
Copy link

@aep aep commented Jun 12, 2018

could a bounty revive interest here maybe?

@kevinelliott
Copy link

@kevinelliott kevinelliott commented Jul 3, 2018

I think this feature is very important.

@flashcode
Copy link
Member

@flashcode 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-zz
Copy link

@jesse-osiecki-zz jesse-osiecki-zz 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
Copy link
Member

@flashcode 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
Copy link

@khronosschoty khronosschoty commented Aug 9, 2018

Please add this!

@KristianLyng
Copy link

@KristianLyng 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
Copy link

@shibumi shibumi commented Feb 25, 2019

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

@weechatter
Copy link
Contributor

@weechatter weechatter commented Feb 25, 2019

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

@flashcode
Copy link
Member

@flashcode 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

@sparr
Copy link

@sparr sparr commented May 13, 2020

@flashcode Could we get a status update over here, more concise than the weechat-relay changelog?

@flashcode
Copy link
Member

@flashcode flashcode commented May 13, 2020

I recently implemented the weechat-relay-cli command line tool to connect to WeeChat.
It's working partially: you can send commands to WeeChat and receive bytes, but the messages from WeeChat are not decoded (this is missing in the lib and requires some work, this is the bigger part in lib).

I have no estimate in term of version or date, the progress is slow, depending on my free time.

@shibumi
Copy link

@shibumi shibumi commented May 13, 2020

@sparr according to the weechat roadmap it will be possible to connect to a weechat relay with weechat in January 2021: https://weechat.org/dev/roadmap/

@leogcurvelo
Copy link

@leogcurvelo leogcurvelo commented May 14, 2020

I'd just like to say that the frowny face reaction in the last comment is uncalled for, and we appreciate your work!

To whomever is unsatisfied with the roadmap, please consider donating: https://liberapay.com/weechat

@craftyguy
Copy link

@craftyguy craftyguy commented May 14, 2020

Uh, the confused face was because one developer says "best effort, whenever I have time to do it" and someone else says "roadmap says X" (when obviously the developer's comment would supercede any potentially outdated roadmap....) I mean, why even reply with a link to any roadmap when the developer literally gave a response to the question.

@flashcode
Copy link
Member

@flashcode flashcode commented May 14, 2020

Yes, the roadmap was just a goal, but there is a good chance features planned will move again to later versions.

The priority for me is to fix bugs and review pending pull requests, and I'm almost alone for this work. There are currently 393 issues and 61 PR, this is a huge work. I'm sad to see that some bugs were opened 6 years ago and still not fixed, and that does not even include the old Savannah bug tracker were some bugs were opened 14 years ago…

WeeChat as a relay client is not on top of priorities, so the progress is slow, sorry about that.

Note about donations: it's good for motivation, but unfortunately I miss more time than money.

Help on WeeChat to fix reported bugs, translate docs, review scripts pending (new and updates) would be appreciated. The less time I spend on this, the more time I have for WeeChat as a relay client.

@flashcode
Copy link
Member

@flashcode flashcode commented May 30, 2020

Some news: as you can see in weechat-relay repository (https://github.com/weechat/weechat-relay), the development is active.

I'm currently working on the binary message parser, to decode messages sent from WeeChat to client. This is the most important part of the library.

The other parts of library are already OK: build of binary messages, send of commands to WeeChat, and a CLI tool to test with a running WeeChat (it still has to be improved with the binary message parser, and some completion can be added as well).

Stay tuned for next news... 😃

@diegombeltran
Copy link

@diegombeltran diegombeltran commented May 31, 2020

Some news: as you can see in weechat-relay repository (https://github.com/weechat/weechat-relay), the development is active.

I'm currently working on the binary message parser, to decode messages sent from WeeChat to client. This is the most important part of the library.

The other parts of library are already OK: build of binary messages, send of commands to WeeChat, and a CLI tool to test with a running WeeChat (it still has to be improved with the binary message parser, and some completion can be added as well).

Stay tuned for next news... smiley

Great job flashcode!

@weechatter
Copy link
Contributor

@weechatter weechatter commented Jun 2, 2020

I guess a donation is welcome :-)

@flashcode
Copy link
Member

@flashcode flashcode commented Jun 5, 2020

The message parser is implemented: weechat/weechat-relay@9c78acf 😃

@iot-resister
Copy link

@iot-resister iot-resister commented Nov 16, 2020

Can I specifically sponsor/donate for this feature?

@flashcode
Copy link
Member

@flashcode flashcode commented Nov 17, 2020

@iot-resister: a donation is always welcome, it's important for the motivation!
But it will unfortunately not speed up a lot the development of this specific feature, which is still active, but the progress is slow as I don't have a lot of free time.

The next steps are:

  1. Use the weechat-relay library to send messages from WeeChat to the client. That means the library must be first packaged in Debian and become a required dependency.
  2. Now that the parser is ready in weechat-relay, WeeChat has to use this parser to connect to another WeeChat as a client. This is the biggest part and requires a lot of changes in the WeeChat relay plugin.
@flashcode flashcode self-assigned this Nov 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet