Skywire Dev
BaBanWhen we connect to socks proxy, is it direct connect to it ?
Or through skywire server then to destination socks ?If you don't have the public autoconnect on, I think it will likely be a direct connection ; but you raise an important point. We need basically status.skysocks or status.skywire for mobile. Not just filtered to one app, but a view of routing for all apps or any app
Y S Skywire DevLink
click to showthat is @mrpalide 's territory. Hmm, I guess there isn't exactly a way to configure the visor for the mobile app in the same way as the linux desktop one or the wasm visor. That was where I would have started with a mobile app, if I had made it: config generation and updating. That needs some page like deb.theskywirenetwork.net/generator but in the actual mobile app itself and specific to the mobile app. Or even a way to manually edit the visor's json config in the mobile app might work. I think we have that as part of the hypervisor UI now, a GUI for configuring or reconfiguring / updating the visor config. based on the UI at deb.theskywirenetwork.net/generator The config version mismatch with the visor version would matter more if the mobile app was reward eligible, because that could make it ineligible if the config wasn't updated for long enough. I think there hasn't been anything added to the visor config that matters for moblie since that version. Maybe the skyDNS but I don't know how that configuration is handled for mobile. ... I try to keep everything in the same format. I've gone to great lengths to make the wasm visor run and behave in the browser tab exactly as it would for a desktop visor - even down to the level of the visor running in the websh terminal for the wasm visor, and the netscrape browser there for the angular hypervisor UI to be displayed in. The config generation happens via skywire autoconfig in the wasm visor. Troubleshooting either skywire on desktop or the wasm visor is basically exactly the same process for both platforms because the process runs in more or less the same way. It's basically a scaled model of the desktop version of the software that runs in the browser. But the mobile app implementation is so inherently different and divergent from the desktop and wasm visor implementations that for me it's like looking at totally different software. I can't just change the mobile app to look and behave as the desktop / wasm
Skywire Dev
YwenaI've figured out what's going on. After the core is launched, when I switch the language, the interface changes, but the notification remains the same@mrpalide make sure to handle the feedback on the mobile app issues, in case you missed these messages
M Link
click to showWe have a channel for bugs and features that guys talk about them here. https://t.me/skywiremobilebugs
Skywire Dev
Ywena / @baban707 can either of you get a screenshot of the transport management interface for mobile or at least the statistics on what transports the mobile visor has? I don't have a smartphone to test or check it with currently.
Skywire Dev
ReplyA TinyGo-compiled skywire visor now runs and appears to function correctly.
329 MB RSS against 516 MB for the native visor, with 286 threads. The binary is 191 MB, against 247 MB native.
15-20 minutes compile time ; 8-13GB ram required.
built with a patched tinygo, I'm still waiting on upstream PI'm still optimizing skywire to work better when compiled with tinygo. It takes 20 minutes to compile every time.
TinyGo visor memory is down to 229 MB vs native's 328 MB. So I'm starting to see performance gains with it, at least in terms of the memory usage.
YwenaPhoto
It is not forced to update the config after each release, but it will become the default in next release, just like on desktop.
BaBanWhen we connect to socks proxy, is it direct connect to it ?
Or through skywire server then to destination socks ?
Same as the desktop app, from the skywire network.
S Skywire DevThis will be significant if the visors can sync transports over existing transports. the transport discovery was (needlssly) sending 10x the bandwidth as it was getting. now it sends less than it gets. the only reason this wasn't done before was that the transport setup node was sortof an authentication point, and it can anonymize the requests so you don't know who is asking for transports from you. But I made the gate just skynet itself. so if you have a transport to a visor you can get its transports. But only over skynet, over dmsg you have to go through the transport setup node. The transport setup node is better for orchestration of transport setup and a bad gate of who can see the transports..
Skywire Dev
I'm redesigning the transport read path
Today every transport has a goroutine blocked in readPacket. It pulls bytes through a stack of readers with io.ReadFull, and the stack only makes progress while that goroutine is parked inside it.
The redesign turns this around. The bottom of each stack would report "bytes arrived" and feed a resumable decoder. The decoder is one state machine: noise frame reassembly, decryption into a reused buffer, then routing-packet reassembly. It never blocks, so anything can drive it. Per transport type:
- sudph (374 of 420 transports): kcp already receives every packet pushed from pfilter. It would queue the session on a small worker pool instead of waking a reader goroutine. That's the same pattern as the send-side pool, which keeps each session's packets in order.
- webrtc (22): dcConn's existing readPump goroutine would feed the decoder directly, removing one goroutine per peer.
- stcpr / squicr (24): these keep their goroutine. Pushing TCP would need callbacks in the net fork's poller, not worth it for 24 connections.
The hard parts:
- The inline handlers (cascade, setup RPC, visor RPC) would run on shared workers, so a slow one stalls every session queued behind it. Each needs an audit.
- When the conn under a transport is swapped, the old one must stop feeding before the new one starts.
- The 3-minute read deadline gets replaced by the existing silence check in tickPing.
For TinyGo wasm, it would help a lot, and that's the strongest case. TinyGo wasm implements goroutines with asyncify. Every goroutine needs its own stack in wasm memory, and every block-and-resume unwinds and rewinds that stack, at a cost that grows with call depth. A blocking reader per transport is the worst pattern for that. If TinyGo wasm is a target, the push model is close to necessary.