PirateBox you might know, is a ‘DIY anonymous offline file-sharing and communications system’, that can run off a cheap wireless router - typically a tp-link tr3020.
I wondered that if the launcher-proxy be run from command-line only, it could act as a simple route allowing access to SAFE. That would not need login or the launcher GUI; so, perhaps would be very light-weight and of a size that could be put to the tr3020 in a way that PirateBox is done.
I see this from a while back re CLI, so perhaps it’s something for the future.
The idea is then that anyone connecting to that wireless point, would be able to access SAFE content without needing to have either the proxy or the launcher installed. Baby step for new users perhaps…
Potentially it’s more tricky if the launcher-proxy is too large relative to the software required for relaying the wireless signal rather than just allowing access to USB files in the way the PirateBox does but perhaps it’s possible… I expect such capability would be practical of course with a PC/laptop + wireless but would be nice if something like the 3020 worked too.
You might be right… I don’t know how simple connecting to SAFE will be. Having options to smooth any wrinkles was what prompted the OP. It would be great, if a one step option was available… add-on are easier to action, than routes that talk of .pac etc.
There’s another use case that might be explored here and that’s creating access points for expanding the network via a mesh network. If one could set up small autonomous nodes that were say powered by solar panels and didn’t require much computing power they could be set up nearly anywhere and act as relay points for accessing the network.
Just last week I was looking deeper into the launcher code base and made a small experiment in which we’d host the HTTP interface directly from safe_core (rather than wrapped from a node-process). In that scenario the binary would provide the entire API and Proxy-Interface directly, which you could start from the CLI. It would, however, not give permission of App-Management (and login) to anyone but only those “apps” which connect with a special (always randomly generated) token. Thus the launcher app could also connect to a remotely-running safe-core instance and “manage” it.
My main argument for this was the reduction in the code base (no FFI stuff, which is almost 30% of safe_core and 20% of the server-side node code at the moment) and mem-copies/round-trips (HTTP->safe_core rather than HTTP->proxy->node-API->FFI->IPC->node-Subprocess->FFI->safe_core). I explored that with krishna and others in the team, but we came to the same conclusion, that while it is viable and potentially interesting, it is weeks of work needed and not of the highest priority at the moment (getting out a working Alpha is, in case that was unclear ).
However, the CLI is an interesting case and very much viable. Maybe I’ll stick together an RFC for that proposal at some point.
not required for a basic access to SAFE websites. I had in mind the most minimum function and expecting that would be very light and hopefully could be put into a router like 3020.
Well, if the server can’t do permission management, you can really only “get-surf” the web…
No website could ever request the users permissions to act in their name or anything like that. For the “size” of the actual binary that even doesn’t make much of a difference anyways – especially if the actual “managing” part is outside of the cli itself.
Yeah, I also thought about neon, but don’t really see the appeal …
WebAssembly is super awesome. I think that’ll be a big deal and also allowed easily distributed, highly performant sandboxed processes… so like computing cloud ideas … that’s gonna be rad.
I have a suggestion for headless Safe. Why not use the safe libs you need (safe_ffi if you’re not in Rust)? If there is concern about keeping libs updated, then just have system level shared libs (e.g. apt-get install libsafe-dev). If credential storage is a concern, require authentication upon start, or use some other credential approach (e.g. ssh agent style). Think more like a DB CLI client (e.g. psql) and less like a “launcher” CLI. The UI/desktop-based app installation process and launcher registration process is, IMO, different than CLI/daemon apps. Just some thoughts…
As for neon or web assembly or any of that…stay as low level as you need until you need to get higher. There is no reason for a headless safe setup to need a JS VM when it’s written in a low-level language. Same goes for app developers (find the lowest common denominator of systems you want to support and write your stuff in that or accept you need independent implementations per platform).
).
) 