Nebulus: An IPFS-Less IPFS
nebulus.dev
nebulus.dev
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...
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.
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!
You might be interested in checking out the rust implementation: https://github.com/rs-ipfs/rust-ipfs
Im not actually sure how well it would work for what youre after, but it is an option!
There is a version of libp2p, which is the library used by IPFS, that is written in C++. Perhaps that is another option.
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.
24MB is just the total for the compressed packages. The ipfs binary is actually over twice that size.
(Your guess may be incorrect)
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.
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.
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)
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.
2) Can someone contrast hypercore and IPFS?
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.
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.
I expect the trouble there would be how the data is chunked. If IPFS disagrees about the chunking we would have different CIDs.
.. also i'd need to implement all of this myself to get it in Rust. Hmm.
Maybe some of the building blocks you need can be found in there somewhere.
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.
There's some documentation here: https://github.com/ipfs/go-ipfs/blob/release-v0.9.0/docs/exp...
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.
Freenet allows connecting only to peers, and is the same sort of p2p hash-based storage cache. It's about as old as Tor.