• via webrtc but is it's network bandwidth utilisation is below 30-50% where it could be 90-95%. ( a. netrwork capacity is 1gbps, b. 100mbps. So if sending is throttled to my receiving capacity it should be around b's capacity. But i'm barely getting near 30-40mbps)

Is parallel connections / multi-threading possible?

edit: Whatever croc is doing seems can use my full badwidth.

• Runs on pushes to all branches (for now, we have some Github Actions minutes to waste!)
• Runs on pull requests to develop and master

Also adds a build badge, which we later can extend with a code coverage badge and a test status badge. The latter badges are both quite finicky to get to work with GitHub, currently.

Hello, i'm trying to send a file using the command portal --verbose send E01.mp4, however it fails almost instantly with the only output being "Error compressing files." What would be a good way to diagnose what's causing the issue? as even verbose mode doesn't say anything in particular

This PR ports the portal module to JS using WASM

I have not yet managed to import the wasm file using a bundler into a js project, but it works very well in a raw HTML file. We would likely want to create a typescript npm module for this package. The question is if we want this in this repo, or a separate one?

The JS interface is not very JS-like, so there is potential for improvement

hi i was just using portal when suddenly Error initializing UI unable to set console to raw mode: The parameter is incorrect. this error came i cant send any files.

any help would be appreciated. thanks

Change that is meant to clean up the API a bit by using functional option pattern for specifying the options.

For instance, if you want to create a Sender with the UI option you would do

sender := New(programOpts, WithUi(uiCh))

Opposed to

sender := WithUI(New(programOpts), uiCh)

By doing this you can more ergonomically add more options to the constructor like this,

sender := New(programOpts, WithServer(serverOpts), WithPayload(buf, int64(buf.Len())))

And adding more options in the future would not change the API.

Generally fails to compress any npm_modules folders that I have tried to send. Most likely this is due to irregular folder or file names in some common module.

Adding more info soon.

(Dev -> Master)

• Remove message size limitations. This broke portal for larger files than 32KB since the latest release which uses the nhooyr/websocket library.

• Sender and receiver had different versions of schollz/pake. The old version in the receiver was broken in go 1.19. (golang/go#50974)

• Upgrade other packages.

This PR does the following:

• Introduces an Init function to internal/sender package so that it can be called from other packages than the main package
• Refactors the rendezvous address to a string rather than TCPAddr
• Implements a separate package from which the portal Send and Receive functions programmatically
• Implements an E2E test using testcontainers, and adds a Dockerfile
• Adds a Makefile so pipeline steps can be easily reproduced locally
• Updates the pipeline and adds new steps

• Moved ready channel into the struct and had WithPayload signal to it.
• Returned websocket connection instead of sending it over a channel.

These changes do not change any behavior

When looking into solving #4 I saw that all flags are shared across all subcommands and that some flags had dual purposes.

For instance the -p flag doubles for specifying the port where to expect the rendezvous server to be running when supplied with the send and receive commands, and when supplied with the serve command it specifies on which port to run the rendezvous server.

I think it is probably wise to separate flags on a per-subcommand basis, as it does not make sense to have a --address flag for the serve command for instance. We could probably still have some global flags like verbose etc that are available to all subcommands.

I think this would be a cool way to display the different stages in the transfer process using the new unmanaged output feature introduced in bubbletea v0.22.0

I wanted to install on an armhf (32-bit arm) host, and attempted to install via go install because the releases only include arm64 binaries.

Error output:

go install -v github.com/ZinoKader/portal/cmd/[email protected]
go: downloading github.com/ZinoKader/portal v1.0.3
go: github.com/ZinoKader/portal/cmd/[email protected]: github.com/ZinoKader/[email protected]: parsing go.mod:
	module declares its path as: www.github.com/ZinoKader/portal
	        but was required as: github.com/ZinoKader/portal

While the password is already pretty short, it requires communication of the password over some other medium for every individual transfer session to establish a connection. An optional feature could be to let users decide on an email/password combination which friends can add to their friends list. This way, when your friend starts a transfer session, you can simply choose their email/name from the CLI and start receiving.

An idea for how to still keep somewhat secure: We would not want to store the credentials on the server (only in primary memory and hashed), just like with the password. To get around this, the transfer session would send the encrypted credentials to the server only when starting a transfer (and these are stored in memory until somebody connects). The recipient would then send the same encrypted credentials to the server, and if there is a match your friend is online and will start the transfer.

By invoking portal send with no arguments the TUI could open an interactive file picker to specify which files to send.

Look here and here for insporation

When I try to run the rendezvous server locally I get this error,

as port 80 is a privileged port and therefore a non-root process cannot use it.

Do not know if it is my setup or whatever but we should probably change it?