meejah / fowl Goto Github PK

debian requires a license and ya thanks

I have a ssh server on the remote end that I want to forward to the local port in order I have to send {"kind": "local","endpoint": "tcp:22:interface=localhost","local-endpoint": "tcp:localhost:2222",} from the remote host. Is there a json string that does this on the local end.

Working with a Haskell GUI running fowl as a subprocess, I needed to set PYTHONUNBUFFERED=1 to make things work.

Ideally some more .flush() calls after emitting messages (or some other fowl-internal mechanism) can get rid of this need.

I seem to observe that it takes quiet a long time for the connection to be restored after a network change (currently I have already been waiting for half an hour and still nothing). Is there anything fowl can do to decrease that delay? Or is it something that is done internally by the wormhole library?

I'm working on it and it builds (I may have stoling the debian folder from magic-wormhole) you get a working deb now to test it with launchpad

These two seem pretty crucial for establishing a session and yet are not described in doc/frontend-protocol.rst.

For some people, having a working Nix setup is important.

It would be beneficial to have one for this project.

It was suggested that supporting UCSPI would be good.

See here: https://cr.yp.to/proto/ucspi.txt

Essentially this means "use pipes instead of local TCP sockets". This would be interesting to support for sure, and a nice design.
Probably means "no windows support" (for this method). Oh well.

Definitely somewhat cleaner, but my experiments with paired Unix sockets didn't make me happy. (I didn't know about this spec and implementations at the time though).

Certainly worth experimenting with and/or supporting (optionally) as a way to read / write streams.

Inspired by discussion from #11 I think it makes sense to split the command-line into two:

• fowld: plumbing command that accepts commands on stdin and produces messages on stdout (i.e. a stdin/out line-based protocol with JSON messages).
• fowl: porcelain for users (everything accomplished by running fowld under the hood)

This means that "integrations" (like https://sr.ht/~meejah/pear-on/) would typically run fowld directly and issue it commands. End-users would typically run fowl ...

So, options similar to ssh's -L and -R can live on the fowl process. The target for these options (and their output) is humans -- friendly text can be produced, and whatever makes sense for humans is what makes sense for options.

On the other hand, the fowld protocol should be well-specified, stable and versioned -- integrations can be confident that a new version won't break their interaction (due to a new or removed option etc). (Note: the protocol is NOT yet in any way stable).

Philosophy-wise, fowld should take very minimal (ideally zero) command-line argument and do all interaction via its well-specified line-based JSON protocol. All output and input MUST be machine parse-able and stable. The fowl command (and sub-commands) produces human-centric input and while it "should" be stable between versions, nobody should depend on parsing it.

I've used the "porcelain" and "plumbing" words the same way Git does. This is an analogy to the fact that the guts of water / waste systems is the "plumbing" like pipes etc (which most humans never see or interact with) while the "porcelain" is the sink or toilet which humans are expected to interact with (so it better be nice!)