This entire project can be replaced in two different ways with just IPFS. You don't have to run IPFS to be able to add files or retrieve them (if you've added them on the same computer), so simply add the files without running the daemon and you're already "Offline and Private" and "IPFS without the Network".
If that's not enough, you can also run your IPFS daemon with `--offline` and it won't connect to any network, giving you another way of using IPFS offline and privately.
If you want to go one step further, when adding files with the IPFS CLI, you can add the flag `--only-hash` and IPFS will only hash the content without actually writing anything to disk, making it even more "offline" and "private".
All in all, this seems to be a project whose author missed to read the documentation for IPFS as everything mentioned is already supported in go-ipfs, the main IPFS implementation.
Hi there, just want to clarify that Nebulus is not a replacement for IPFS or competes with IPFS. In fact it internally uses all the features you just mentioned. In fact it's even powered by JS-IPFS and makes use of the "--only-hash" features and other features you mentioned.
I needed a programmatic way to do all these things (as well as many other user friendly features that the IPFS raw protocol will never provide) and the existing IPFS libraries don't provide a way to do so, so I built it and have been using it from another project, and it was so useful that I decided to extract it out of that project into a standalone one. Just hope others find it useful as well. Thank you.
I see the “ipfs less” terminology as similar to the term “serverless”. Just like how serverless still has servers but the point is that you don’t have to maintain your own server, ipfs less does make sense in that you don’t have to run ipfs node to use it. But also just like how many people hate the term serverless, ipfs less will be hated by many as well. I guess at the end of the day what’s important is whether something provides value, and I think this is pretty cool technology in that sense. Just my two cents…
The project looks useful and great, but I very much hate calling it "IPFS-less". Not only is it incorrect, it increases confusion regardless of how technical of a user you are. It is also unattractive - if it isn't IPFS (except it is), tell me what it is or does instead!
Really terrible branding; consider that the currently top-voted comment has read the site enough to formulate an alternative design and still has completely misunderstood how this relates to IPFS. The rest of the site is neat, though! I hope the author reconsiders!
Any ideas on the future of reduced-size IPFS utilities. For example, the go-ipfs Linux packages are somehere around 24MB. Is this a problem anyone is working on.
People are working on smaller unixy tools to do fewer things well, but at least for the main codebase we are limited by go itself. Making binaries smaller is not simple at all...
I use a text-only browser. It does not automatically source resources external to the page. I do not experience "heavy" pages. What you refer to is probably what happens when pages try to source a gazillion different resources.
I mean, if you are on a sufficiently-embedded system that you don't have 24MB of disk space, you almost certainly don't have enough RAM or CPU to run IPFS anyway.
In some cases I have 24MB but I want to conserve space for other programs. The go-ipfs uncompressed binary is 56MB not 24MB.
That is a multiple times larger than the combined size of the kernel and userland I use.
Seems like making ipfs run on smaller systems is a goal some are interested in pursuing. I could be wrong but I doubt I am the the only one interested in this.
FWIW, most Raspberry Pi based systems are not what I would want to call "embedded"; and, in the grand scheme of things, they actually have fairly large CPUs. I am surrounded by such devices, and they all have plenty of storage as SD cards don't even come in tiny sizes anymore... I imagine we are simply at a point in time where the cost of creating an individual object encased in a plastic shell has high enough intrinsic overhead that having less than a gigabyte of storage would be nonsensical.
FWIW, OpenWRT is used for more than just RPi. Also, I never said "embedded" was the only use case. The categories were 1. embedded 2. small form factor computers with limited resources 3. older computers. That is a quick list, not a fully inclusive one. To be truthtful, I am not comfortable with 56MB binaries even on newer laptops where I have GB of free space.
I simply cannot agree with any comments that imply that keeping size small is a worthless goal. I could list hundreds of past and current examples where people are trying to reduce size and/or complaining about large size. k/shakti fits in a 2000's-era CPU cache. Arguably it does more than go-ipfs. At least, one can certainly do more with it.
It makes no sense to argue against making programs small, for a variety of reasons I am not even bothering to mention. Large programs offer no additonal benefits. Generally, no one is forcing anyone else to use smaller, faster programs if they do not want to, UNIX utilities being one obvious exception; there are others.
I will continue to write, use and appreciate smaller, faster, more resource-efficient programs. I am not the only one. You will have many more folks than just me to convince that they should ignore size.
Reminds me of Camlistore, one of the earlier content-addressable personal storage systems, by Brad Fitzpatrick. Now called Perkeep apparently https://perkeep.org/
What's the use-case for this kind of usage of IPFS? Is it just a generic content addressable store for local use? Like perhaps use it to compile and install packages that you symlink into your system path a bit like DIY nix?
Looks great, thank you for presenting it so thoughtfully too.
Do I read correctly to mean Nebulus could potentially be used as a replacement for p2p file xfer, such as per wormhole? Any caveats with such a usecase?
(Also, just FYI there's a one-letter typo with the first sub-title under API)
Any application using content addressing can make use of at least some IPFS technologies. Sharing the contents of /nix/store on a local network or VPN is something I've been thinking about recently.
Hypercore distributes signed log-based structures addressed by pubkey. It embeds indexes in each log entry to make this perform well; for instance Hyperbee is a b-tree over a log. (See https://github.com/hypercore-protocol/p2p-indexing-and-searc... for how that works.)
IPFS distributes content-addressed blobs which interlink to form DAGs. Mutability is supported by pubkey (or similar) pointers to recent hashes.
I work with Hypercore. It’s often a matter of preference between them.
I mentioned this in above thread, but I am thinking of ways to mash up Nebulus with Hypercore (Because the content addressable aspect has been unbundled from the networking aspect of IPFS, I think there will be some interesting ways to deliver IPFS over Hypercore). Will keep the hypercore community posted when I make some progress, and thank you for all your work with Hypercore. I use Hypercore for several of my projects.
What's the performance like for hypercore? How long does it take for updates and new data to propagate the network? What type of throughput do you get for uploads and downloads?
> 1) I wonder why this wasn't written in a language that can compile to wasm, so it could be used on both native and js without reimplementing.
The most straightforward answer is, I extracted this out of an existing project I've been working on: https://rarepress.org/ I had to build a system that makes use of IPFS without having to publish everything to the public network, and this was where the idea came from. But the "IPFS-Less IPFS" turned out to be much more powerful idea than I originally thought, so decided to turn it into its own open source project.
That said, I think it shouldn't be difficult to implement this using Go at some point if this approach becomes popular. For now I wanted to keep the initiative minimal so I can move fast.
> 2) Can someone contrast hypercore and IPFS?
This is a great question in this context. Hypercore is more focused on the networking aspect, but IPFS is not just a networking protocol but also a way to represent files using immutable identifiers (content addressable file system). What I just did with Nebulus is unbundle the "file system" from the "network" so we can use IPFS in more flexible manner.
Speaking of Hypercore, because Nebulus unbundles the network aspect of IPFS from the content addressable file system aspect, it is possible to use ANY network transport to replicate IPFS files, which includes Hypercore.
Not implementing the core of the protocol in something portable-library-friendly has been a real drag on IPFS. It's made it, in practice, more of a program than a protocol.
The counter-argument is that they'd not have made so much progress in the first place, in the short list of languages that qualify as portable-library-friendly.
What I really want is a private, secure IPFS. I do want the network functionality, but I want it to exist only between my nodes. I know I can pin encrypted blobs, but I want something that handles this transparently. Is this possible somewhere?
Yeah. You'll need to run your own bootstrap node(s) and create a custom key for the swarm. IIRC that's about all it takes.
A bootstrap node is just any node that's (more or less) permanently reachable on the public Internet. Same as lots of tech like this, IPFS needs them for initial peer discovery and (in many cases, and I'm guessing in IPFS' case as well) NAT-breaking, plus as a route of last resort.
If that's not enough, you can also run your IPFS daemon with `--offline` and it won't connect to any network, giving you another way of using IPFS offline and privately.
If you want to go one step further, when adding files with the IPFS CLI, you can add the flag `--only-hash` and IPFS will only hash the content without actually writing anything to disk, making it even more "offline" and "private".
All in all, this seems to be a project whose author missed to read the documentation for IPFS as everything mentioned is already supported in go-ipfs, the main IPFS implementation.
Edit: the title "IPFS-less IPFS" is fun too, since nebulus seems to include ipfs-core as a dependency, not really IPFS-less then I'd say :) https://github.com/skogard/nebulus/blob/480d43dc22ccd949c6ae...