Thanks for this, it's pretty cool concept. ~~It would be cool if we could set a password to restrict the stream to just selected users. Is that on the to-do?~~ [Edit] I just saw it's planned, sorry.

Any plans on adding build instructions? I'm not a big fan of downloading precompiled binaries, which also makes it more difficult to upgrade than just git pull and build. It would also allow using tstream on ARM devices, which are now very widespread.

Not related, but I may as well mention it just in case: while the stream worked flawlessly when viewed on a Debian machine in Firefox and Chromium, glitches appeared on my Solus machine from Firefox (Chromium not tested) with part or all of the text being rendered as square characters, mostly $PS1, but not only. In Nyxt browser, the web page only shows up briefly before it turns 100% white with nothing displayed. Both issues are probably not related to tstream itself and may be just local issues but never know, maybe tstream uses something that is not properly supported in all configurations.

What is tserver used for? Is that for hosting your own instance of the website?

TL;DR:

• we stream data in block( contains many write requests in one block )
• Now users watching the stream will be delayed with the actual stream
• Much smoother and less lagging for both streamer and viewer
• Streamers need to upgrade to version 1.3.0 to be able to stream

Technical note

In the previous version, any single change on the streamer's terminal is sent to the viewer. There are some problems with this approach:

• Many changes are very small ( I.e: newline ) => inefficient use of request
• In a short period of time we have many changes => too many requests With this version, we send messages by block. Each block is all messages generated in a period. This block is also being gzipped before being sent. This way we have some advantages:
• fewer requests since we send a block of data every x (3) seconds.
• By gzipped we reduced the message's size by around 7 folds. also, gzip is very fast so it's not a problem.

But this prevents users from watching the stream in super near real-time.

But I think 3 seconds lag is fine, it's how youtube and twitch works anw.

Important

All tstream client has to upgrade to v1.2.0 to be able to stream

Server

• Add an SFU voice server. Currently only allow one producer for one room ( still has some bug with syncPeers )
• Changed all the messages to using JSON (used text on the previous version) => this affects all components

TStream client

• Add voice command /unmute and /mute
• Allow 3 chars roomname

Viewer UI

• Add simple search for live stream in home page
• Add volume control in room
• Responsive for mobile

Doc

• Add discord server in README

Server

• Add an SFU voice server. Currently only allow one producer for one room ( still has some bug with syncPeers )
• Changed all the messages to using JSON (used text on the previous version) => this affects all components

TStream client

• Add voice command /unmute and /mute
• Allow 3 chars roomname

Viewer UI

• Add simple search for live stream in home page
• Add volume control in room
• Responsive for mobile

Doc

• Add discord server in README

TUI chat

• Start with command tstream -chat. It'll auto-detect streaming session to open chat

Improves and secures streamer - server connectivity

• Add authorization for streamer connection.
  • Streamer connecting flow:
    • Send a POST API to the server to request create room. this request contains a secret that'll be used as the room's secret
    • Initialize a WebSocket connection
      • Send a secret
      • server verifies. if match with room secret => authorize connection

CHAT

• UI refactor a bit. but still needs a lot more work
• UI add /name command so viewers can change their name
• server => refactor message packaging

Server

• add boltDB : this DB acts as a permanent cache. Currently, it only stores room info.
• There is a coroutine to periodically sync state from RAM to DB
• add a new app: POST /api/room : streamer must call this to request create room before connecting via WebSocket. This API performs some checks:
  • version checking of TStream. if the version is not compatible => return 426 to streamer
  • In case streamer requests to add a room already existed => user wants to reconnect, or maybe the room is taken by someone else. The server then checks the secret of the request with the room's Secret => if match then allows users to proceed

TStream

• Add check if the user starts TStream inside a TStream session: using TSTREAM_SESSION env
• When TStream is started it will generate a config at ~/.tstream.conf. Currently store: secret, and username
• Version checking, display message require user to upgrade if fails

Viewer

• Add show recent streams on home page
• Improve room state checking to display the right status
• Improve responsiveness

First I started tserver

$ ./tserver 
TStream server v1.3.2
Serving at: localhost:3000

When another terminal is opened and TStream is launched with the same option as an example, streaming starts with https://tstream.club/

$ ./tstream -server http://localhost:3000                                                                                             
TStream v1.3.2                                                                                                                                                 
✔ Username: █atoken                                                                                                                                            
✔ Stream title: hoge█                                                                                                                                          
Press Enter to continue!                                                                                                                                       
🔥 Streaming at: https://tstream.club/matoken 

If you change the server fromhttp://localhost:3000 to http://localhost:3000/, it has become an error

$ ./tstream -server http://localhost:3000/
TStream v1.3.2
✔ Username: █atoken
Stream title: hoge
Press Enter to continue!
Failed to connect to server
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x6575a2]

goroutine 1 [running]:
golang.org/x/term.restore(0x0, 0x0, 0x0, 0x1c)
        /go/pkg/mod/golang.org/x/[email protected]/term_unix.go:57 +0x22
golang.org/x/term.Restore(...)
        /go/pkg/mod/golang.org/x/[email protected]/term.go:43
golang.org/x/crypto/ssh/terminal.Restore(...)
        /go/pkg/mod/golang.org/x/[email protected]/ssh/terminal/terminal.go:64
github.com/qnkhuat/tstream/pkg/ptyMaster.(*PtyMaster).Restore(...)
        /go/src/github.com/qnkhuat/tstream/tstream/pkg/ptyMaster/ptyMaster.go:90
github.com/qnkhuat/tstream/pkg/streamer.(*Streamer).Stop(0xc0000c5220, 0xc00002a4e0, 0x1b)
        /go/src/github.com/qnkhuat/tstream/tstream/pkg/streamer/streamer.go:272 +0x10f
github.com/qnkhuat/tstream/pkg/streamer.(*Streamer).Start(0xc0000c5220, 0x1b, 0xba69d9)
        /go/src/github.com/qnkhuat/tstream/tstream/pkg/streamer/streamer.go:90 +0x3f8
main.main()
        /go/src/github.com/qnkhuat/tstream/tstream/cmd/tstream.go:165 +0xb25

Debian sid amd64 environment tserver_1.3.2_linux_x86_64.tar.gz And TStream_1.3.2_linux_x86_64.tar.gz was used.