Experience report by m-a-t #71
Comments
|
Dear @m-a-t thanks a lot for sharing your experience. I like your suggestions and some of them are already discussed though not yet planned for incoming version. @sahib will weight on this more, but we will work on web gateway in future versions. Our current focus is to squash bugs, with speed ups when it possible. By the way, fuse layer probably would not work on Mac. The fuse module https://bazil.org/fuse seems to depreciate Mac support.
I am not sure what do you mean by above, could you please elaborate. Summary of enhancements with partial overlap of current enhancements
|
|
Cool, thank you @m-a-t!
While I'm happy that it seems thought through, I'm of course more interested in what seemed complicated? And what would you strip away from brig to make it a simpler tool?
Yes, those are actually the selling points of brig over syncthing. It's just that syncthing really works well, while brig is still work-in-progress and IPFS performance is not convincing enough yet. But we'll get there slowly... hopefully.
As @evgmik mentioned, we never really tried it on macOS. We have to rely on community efforts to get proper support there.
Good news then: I want to support something like
Yes, it hides a lot of the complexity of reaching by delegating that to IPFS. Drawback is that debugging it is a bit harder (or less used to), when IPFS doesn't figure out how to find the repo.
The version control system in brig is similar to and inspired by git, but not the same. There are no branches and the myriad of things that git supports. I probably could have implemented the current concept by using And although
Hmm, that used to work at some point. Will fix.
Yes, we have a ticket and implementation idea here: #48
Yes, that's already on the roadmap, but not feasible at the moment.
That already supported on the command-line ( To add on the summary list of @evgmik:
|
|
Thanks for your responses and sorry for the long delay.
My concern is that the setup procedure will keep many potential users away which are not that technical. I do not propose to remove features and I do not have a simple path to success here. However, there should be a dead-simple way to run a brig node. (Maybe even from a web browser, without even installing something!) On the longterm, success of a tool depends on popularity, number of users. Instead of asking what should be removed, lets approach the problem from the other end: What is the absolute minimum that a user needs to do such he/she can share files as a brig node? Generally speaking, for every configuration degree of freedom, set sensible defaults if possible. Example use case: Sharing a repo with a non-technical user, without usage of a gateway. Try to minimize the steps required for the non-technical user, such he/she can access files of the repo in the webbrowser. |
Uh oh!
There was an error while loading. Please reload this page.
I invested a few hours evaluating brig for my usecase. Here is my experience report. I am happy to provide more details or to open issues for specific topics, if there is need for it.
Was it easy to get »brig« running?
Installation was easy for me because it was packaged in the nix package manager. I already had ipfs-desktop because conducting experiments with different ipfs tools.
I encountered an error on my first computer, when trying out the gateway browser interface. The upload button didn't work. This was the first occasion I gave up. Later I tried it on another computer, where it worked. Maybe this was due to an ad blocker, but I am not sure.
Was it easy to understand its concepts?
My first impression was: It's complicated, but seems well thought through. If possible, I would like to find a tool with simpler concepts. But so far I didn't find such a tool.
What is your intended usecase for it? Could you make it work?
I am looking for p2p/distributed way to share and store my files. It must allow me to use storage from my own server and not force to buy a subscription. So far I was quite happy with syncthing, but what I would like in addition is:
I have not come to a final decision yet, but so far brig seems to be the closest I found for my use case.
I did not test the FUSE part, didn't work on Mac out of the box, but I don't need it right now.
If no, what's missing in your opinion to make the usecase possible?
The biggest missing point for me is that the cool thing from ipfs, a stable link which identifies the file content as itself, is not used for sharing a file. brig offers a link like
http://localhost:6001/get/README.md.However, I would like to provide a link which identifies the file exactly (like a ipfs hash), which even remains available if the brig repo contains a newer version of the file. For example
http://localhost:6001/get/<hash>Anything else that you feel free to share.
I really like the way how repos can be added as remotes with the fingerprint, this is what I found missing in git-annex.
The web GUI is a nice piece of work. I had problems with login after starting a second repo with gateway on the same computer (different port), but after configuring "brig cfg set gateway.cert.redirect.enabled false" the problems were gone, not sure whether this was the reason.
My gut feeling, without trying to understand it further, is that using an own version control could be problematic and hinder widespread adoption. I like the attempt to make a simpler version control than git. However, couldn't git itself be used for all the metadata, readable even without brig installed, and brig just implements a simpler interface how to modify this git repo? (This is was I found elegant in git-annex, it uses git for storing its metadata, instead of inventing some other stuff)
Simplification proposal: If the brig command is run while current working directory is inside a brig repository, this automatically could choose this repository.
Enhancement proposal: Allow publishing a file without encryption, such that it can be retrieved in ipfs without using the brig gateway. My personal preference would be an unencrypted repo, where the share link contains the ipfs hash.
Enhancement proposal: It is a little bit too easy to lose data. A way to ensure that n pins of a file still exist would be nice. I think you already have this on the agenda.
Enhancement proposal: Allow uploading a whole folder, not only files.
The text was updated successfully, but these errors were encountered: