Hello everyone,
Some questions:
Can the public/ folder be “mounted” on the file system so I can just interact with the files with finder (a la dropbox)?
Is there a command line to add an entire folder?
1 Like
FUSE is your friend here, either in js or rust or whatever you wish. CBFS is best win fuse type thing, but FUSE is good for mac/linux. There are a few libs and it would (IMO) make a very good core attribute fro the RFP process.
[EDIT I should add I did this in the c++ code ages back, mount a drive on login, set ethe $HOME var in the env (not great) as this drive and then your home dir is actually on the network, pretty cool as all apps become SAFE apps 
). If we did this cross platform and via a login proper (PAM etc.) then any computer could become yours easily on login]
9 Likes
Thank you for your reply @dirvine
Is there a FUSE integration with SAFE right now? and if so where can I find some documentation on it?
Is there a command line to add an entire folder to public/? e.g in IPFS one can simply do “ipfs -a folder/” to add an entire folder in the command line
2 Likes
No not at the moment 
, we have not cut it over from c++ yet. Not on immediate roadmap, but I feel this one is pretty important for desktop integrations.
4 Likes
Ah I should have said, you can add folders from the demo app, but not from cmd line, may be a neat addon we can incorporate. IPFS has a few good neat features we should emulate / copy / enhance/ work with them on etc.
1 Like
@cretz built a simple command line utility that doesn’t quite do this, but is close. I think it still needs porting to the new API before it is useful again. It was great for testing and once it supports file/directory copy would do exactly what @heliumcraft asks here.
And so it starts…
But it should be
“pretty important” is an understatement David. In my view it will bring adoption to critical mass in less time than it takes to say “who uses Dropbox anymore?”.
As recently noted this integration app should get prioritized and crowdfunded same as browser.
6 Likes
IMHO it’s okay, that such kind of integration is not on Maidsafe’s roadmap, because I think with the current API such thing could already be created by any developer out there. I think that’s also what David meant with
3 Likes
Its a perfect app for an independent developer, particularly as they can look at the C++ code to see how that works and port it to Rust. I took brief a look at it a long time ago but didn’t go very far into it.
As David says, it would be perfect for a community funded project, although I think for the right developer they could just go ahead and I’m thinking it would be generating a lot of PUT revenue for them
6 Likes
Missed it. Thanks…
2 Likes
yes you can use a REST API to achieve this.
That’s great! what about re-publishing the folder to domain X (like in the demo), is that possible through the cmd line or REST API as well?
Although I don’t think I’ll be the one implementing it, I think it should not be hard to do. But I strongly suggest NOT using the launcher/API for this, but rather statically link the Rust libs directly. Then tie it to fuse for nix/bsd/osx or dokan for Windows. Both offer fairly easy to use C ABIs that can easily be wrapped w/ “Rustful” FFI.
1 Like
Can you explain why, I’m guessing performance… but?
The obvious downside of this is presumably that the user would have to enter their credentials twice, once to mount the drive, and separately with the Launcher.
Yup, performance. Yes, the credentials would have to be entered twice…the launcher is really nothing more than an “app” itself like this would be (directly distributing the shared libs itself). There can be approaches to share credentials if that’s really warranted. But IMO the community is just going to have to face the fact that, with everything open source, not everyone (devs or users) will use the launcher (especially if there’s a killer “app” outside of it) and the cool part is they don’t have to.
4 Likes
I think you are atypical and that most people will go for convenience.
The point here is that you “strongly” prefer one option. That’s fine, but not a reason for an app developer to choose it if the alternative will be adopted by more people.
You and others can always build the alternatives that you prefer and that’s good = choice.
Where the trade off is convenience v security, I think we have to be careful, but with convenience v performance, and therefore adoption, I don’t think you have such a “strong” 
case. No doubt we’ll have both options in due course.
Implementing the “file management” part of the example app as a command line thing is a fairly simple exercise thus creating a manual safebox like thing.
Is that a thing anyone would deem relevant and why would you rather have that than simply firing up the sample app to upload / download your favourite things?
(Asking since it’s simple enough to implement that I could make it the sample app of my .Net LauncherApi client)
1 Like
I was looking at implementing FUSE via Java JNR. If written in a modular way, I suspect it would be fairly easy to migrate from using the REST API to the FFI library directly, once the concept has been proven.
I am in the middle of implementing a Java interface to the REST API, which I have a few plans for, with FUSE being one of them. Naturally, it will all be open source too.
I envisage that replacing FUSE and using a different mechanism to mount the Safenet file system should be straightforward too.
I am also considering adding safenet support to an open source Java based FTP server, to provide some flexibility here too. As the FTP server will be able to run anywhere the Safe Launcher can, it would allow 3rd party apps which mount FTP end points as drives, without FUSE or other specialist interfaces. Sure, performance will be lower, but it may be decent enough to provide something useful.
I have a paternity break coming up soon and plan to use the time between feeding/changing bums wisely!
3 Likes